Live data from Hacker News

Show HN: SlikSafe – A decentralized, end-to-end encrypted alternative to Dropbox

news.ycombinator.com

1–10 of 194 posts

Show HN: SlikSafe – A decentralized, end-to-end encrypted alternative to Dropbox

#1
Hey folks,

We are the team behind Slik.

Over the past year, we have been hacking on SlikSafe [1] a Dropbox alternative where all your data is first encrypted on your own device and then stored on decentralized storage.

Some features we're most excited about are -

  - multi-device data sync,
  - auto-backups via desktop apps,
  - search your docs by name or contents with end-to-end encryption,
  - easy sharing via email, QR-code or private-link,
  - Password-less login using MetaMask/Phantom

We leverage storage providers IPFS and Storj for global redundancy, reliability, and immutability.

You can use our web app [2] and macOS app [3] today. Our desktop app for Windows is currently in beta, and will be launched in early Jan.

You can read our WhitePaper [4] for the technical implementation, or see a quick demo [5] of the product.

Would love to hear what you think.

Arpit, Charvi

[1] SlikSafe: https://www.sliksafe.com

[2] Web app: https://app.sliksafe.com

[3] macOS app: https://sliksafe.com/downloads

[4] WhitePaper: https://sliksafe.com/whitepaper.pdf

[5] Demo video: https://www.loom.com/share/abe133c4ce874655a952a30601e99408

Re: Show HN: SlikSafe – A decentralized, end-to-end encrypted alternative to Dropbox

#3
post #2

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?

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

Re: Show HN: SlikSafe – A decentralized, end-to-end encrypted alternative to Dropbox

#4
post #2

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?

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.

Re: Show HN: SlikSafe – A decentralized, end-to-end encrypted alternative to Dropbox

#6
post #4
post #2

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?

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…

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.

Re: Show HN: SlikSafe – A decentralized, end-to-end encrypted alternative to Dropbox

#7
post #4

Earlier quoted context omitted.

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…

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.

Re: Show HN: SlikSafe – A decentralized, end-to-end encrypted alternative to Dropbox

#8
post #2

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?

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.)

Re: Show HN: SlikSafe – A decentralized, end-to-end encrypted alternative to Dropbox

#9
post #4

Earlier quoted context omitted.

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…

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.

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.

Re: Show HN: SlikSafe – A decentralized, end-to-end encrypted alternative to Dropbox

#10
seems v cool and I hope y'all are successful (although I personally prefer to pay for things with regular $s). After reading the marketing site though I'm unclear on whether decentralized storage in this context is the same as a CDN(content delivery network)?
Post reply on HN