Show HN: A Decentralized, End-to-End Encrypted Alternative to Dropbox

And, perhaps more interestingly, why would this become popular where BT Sync failed to live up to the hype?

Furthermore, storage can be paid for by crypto. Does this mean the storage is linked to some kind of cryptocurrency, or is there some kind of central payment system that converts crypto into actual value in the system?

However, we also have an email sharing solution already integrated into the app which uses public-key cryptography. This is protected from accidental leaks as you correctly pointed out.

Thanks for the feedback, we would update our WhitePaper with the details from above, and also indicate that to users in the UI - so that it scares people less! ;)

If a passphrase was lost, the security of every past file would be at risk.

This is what has kept me from approaches like this in the past.

For me the problem with IPFS is - it is just not interesting enough. It's not a storage solution, it is distribution and caching mechanism. You can't really upload to IPFS, you can only publish via IPFS - the same way you publish via HTTP.

I'm trying to decode the trend for decentralized services. If you have a sec:

Q1: In your case, why did you opt for decentralized storage?

Q2: Which benefits do I get as a consumer that I wouldn't if this was encoded, but centralized with a lot of redundance?

Don't take me the wrong way, really trying to understand where this is all going.

Cheers

  1) a Linux app
  2) an Android app
  3) on-demand syncing, aka "smart sync"

I think the bigger problem is that both iOS and Android are doing everything they can to deprecate the concept of a filesystem. Android has a history of killing filesystem features, receiving tons of developer backlash, and then hacking in workarounds with reduced performance. I think the writing is on the wall.

In my experience, porting general purpose tools to Android is a nightmare.

Hopefully something like pinephone gets good enough before things are too bad.

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.

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.

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

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.

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

(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 do you prevent yourself from serving a compromised iOS/Android/Mac/Windows app? Same answer.

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