4 ms·

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 wit

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?

arpitagarwal 5y ago
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 https://sliksafe.com/whitepaper.pdf
- hedora 5y ago
  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.)
  - spiderice 5y ago
    How is this problem specific to web apps? How do you prevent yourself from serving a compromised iOS/Android/Mac/Windows app? Same answer.
    - edoceo 5y ago
      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)
      - hedora 5y ago
        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.)
      - deleted 5y ago
        [deleted]
    - hedora 5y ago
      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).
      - sroussey 5y ago
        So the distribution is the one that alters the code and same issue.
        progval 5y ago
        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.
    - Strom 5y ago
      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.
Comevius 5y ago
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.
- arpitagarwal 5y ago
  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.
  - arpitagarwal 5y ago
    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.
  - Comevius 5y ago
    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_Pattern_Hiding_in_Searchable_Encryption 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.

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?

arpitagarwal 5y ago

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 https://sliksafe.com/whitepaper.pdf

hedora 5y ago
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.)
- spiderice 5y ago
  How is this problem specific to web apps? How do you prevent yourself from serving a compromised iOS/Android/Mac/Windows app? Same answer.
  - edoceo 5y ago
    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)
    - hedora 5y ago
      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.)
    - deleted 5y ago
      [deleted]
  - hedora 5y ago
    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).
    - sroussey 5y ago
      So the distribution is the one that alters the code and same issue.
      - progval 5y ago
        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.
  - Strom 5y ago
    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.

Comevius 5y ago

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.

arpitagarwal 5y ago
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.
- arpitagarwal 5y ago
  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.
- Comevius 5y ago
  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_Pattern_Hiding_in_Searchable_Encryption 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.