Hacker News Reader

Comment by woofcat | Hacker News Reader

If you are offering a Web App doesn't that imply that you're storing a set of Encryption Keys? If you are does that not allow you to access any files stored with Slik?

View on HN

According to their whitepaper the encryption keys stay on the device and can be only recovered with a seed phrase which Slik has no access to, allegedly. There is no source code to verify the details, but they use AES-GCM. That either requires hardware support or a technique called bitslicing to be secure, but it runs on the client, which is fine. The confidentiality of the data however might not be protected because the storage can see the access pattern of the chunks. This is not even theoretical, keyword recovery can be trivial because of a search protocol.

We could definitely expand on the search protocol in our WhitePaper, thanks for the input! However, we provide client side search and not server side search, thus, our servers have no idea of what the user is searching.

The keywords (along with other file metadata) are also encrypted using the user's key, so analyzing access patterns of the chunks, would not be possible for us.

To explain this in detail -

The encrypted file metadata (and the search indices) are downloaded at once. It is then decrypted using the user's key on device. The user then performs a client side search to get the relevant file-ids. The file-ids are then used to retrieve retrieve the file from the decentralized storage.

Client-side search is secure if the client downloads all the metadata, and then nothing else based on the result. The access pattern is simply which and how many encrypted chunks are selected. If they are selected based on a search result there could be a statistical correlation.

Not that every leakage is critical, for example if you write chunks when the user uploads a file the client just leaked that an upload happened, it also leaked how much data was written. Depending on the use case this might not lead to sensitive information leakage. It however might, for example if a hospital has an app that let's you download information about your disease an adversary could leak which disease you have without compromising the encryption.

The most advanced technique of hiding which chunks are accessed, or whether they are written or read is called ORAM. ORAM makes chunk accesses indistinguishable, however this technique has a logarithmic overhead, it fails to hide how many chunks are accessed, and it is also hard to design a search protocol on top of it that does not create patterns in the ORAM accesses, which can be also analyzed.

A practical solution is a search protocol that tries to decouple the results from the accesses.

https://www.researchgate.net/publication/356077294_Access_Pa...

This paper is just an idea, I'm designing a different protocol that is more efficient, but requires persistent client cache, which is just becoming a reality for web clients.

> thus, our servers have no idea of what the user is searching.

Until you all are coerced by some legal authority to code a passphrase intercept into the client ala ProtonMail, right?

Great question - we just keep the encrypting keys on the user's device and in-memory. The keys are encrypted using the user's seed phrase that is only known to the user, and not to Slik.

Feel free to read more implementation details in our WhitePaper - https://sliksafe.com/whitepaper.pdf

How do you prevent yourselves from serving a version of the web app that sends the user’s seed phrase to yourself?

(A malicious employee could do such a thing, or you could be legally obligated to do so in order to continue operating in certain jurisdictions.)

How is this problem specific to web apps?

How do you prevent yourself from serving a compromised iOS/Android/Mac/Windows app? Same answer.

Isn't this a promise of open source? User doesn't have to get a binary from someone, they could, build from source (given experience+time)

Even for closed source apps, reverse engineering efforts (for sufficiently popular binaries) often find backdoors. This sort of auditing only works because each end user gets the same binary blob. (And if not, there’s a reasonably high likelihood of detection.)

Well, for traditional Linux desktop apps, the distribution audits the code + ships the binaries.

For app store based distribution, the developers can set up a deterministic build, and end users can verify the checksum of the package matches the developer’s published source code (signal supports this).

So the distribution is the one that alters the code and same issue.

The distribution can alter your browser/kernel/...'s code anyway. So you are not adding a compromise vector by using one more package provided by the distribution, as opposed to getting the package from a third-party.

The problem with web apps is that the user doesn't really have any control over updates. With a regular app you can verify a version and stick to it. The web version can change at any point with no notice.

Additionally, a regular app can be signed by a key from the developers that you can verify. With a web app you don't even know if it comes from the developers or if you're being MITM-ed because someone managed to get a SSL certificate for your domain. The certificate isn't the only angle of attack either, your CDN or hosting provider might be hacked. Yes the CDN that hosts the regular app can also be hacked, but that will only work against brand new users, because existing users can already know the signing key and the hacked binary won't have the correct signature.

Reply on news.ycombinator.com