We use Syncdocs (https://syncdocs.com) to do end-to-end Google Drive encryption.
The keys stay on the client. It is secure, but means the files are only decryptable on the client, so keys need to be shared manually. I guess security means extra hassle.
Since ente.io's server is just an object storage, I feel at some point either ente or someone else is going to make a drive app for it.
My understanding was that Tarsnap was just fine and that was the preferred solution for Hacker News outside Dropbox.
Nice to see that Tresorit didn't have any serious issues in this analysis, I've been using that for a long time and it works really great, also one of the few players that have a really good Linux client.
The two vulnerabilities they found seem pretty far-fetched to me, basically the first is that a compromised CA server will be able to create fake public keys, which I honestly don't know how one could defend against? Transparency logs maybe but even that wouldn't solve the issue entirely when sharing keys for the first time. The second one around unencrypted metadata is hard to assess without knowing what metadata is affected, it seems that it's nothing too problematic.
curious about iCloud with Advanced Data Protection enabled
Considering iCloud does have some documented cases of silent corruption, such as of original resolution media stored in Photos, it might not be the best choice.
Hmm, I wish the author had reviewed Proton. I think it's kind of seen as a meme here? But I heavily rely on it and generally the Proton ecosystem is getting better and better from a UX perspective
I think Proton is more viewed as a honeypot
I have not seen this take before, do you have any pointers to someone making this claim?
Founders with US affiliation/physicist creating crypto products [1], faulty claims how the relevant Swiss law (BÜPF) applies to them [2], doing crypto in JavaScript on the client side, etc. To me, this smells like Crypto AG [3][4].
[1] https://proton.me/about/team
[2] https://steigerlegal.ch/2019/07/27/protonmail-transparenzber...
Is the suggestion that founders who have US affiliation are automatically in bed with three letter agencies?
From my reading, the “ProtonMail is a honey trap” meme seems to be a popular rumor. Seems like there might be some smoke, but I haven’t seen any fire.
Interesting breakdown[1] of one of the claims that E2E encryption on ProtonMail is broken.
I’m assuming that Proton storage is a product from the same team as ProtonMail.
So what's the alternative?
It's too bad they focused on commercial closed-source solutions providers. The ecosystem would have really benefited if they had put their efforts to, for example, do the same work with NextCloud.
NextCloud has already been analyzed by some great people (https://eprint.iacr.org/2024/546).
That was a good skim for me as someone who implemented one of the first independent mega.nz clients. Useful to know especially about structure authentication and ability to swap metadata on files and move files/chunks of files around when server is compromised, when there's no e2e authentication for this. Lots of traps all around. :)
Looks like the safest bet is still to just tar everything and encrypt/sign the result in one go.
I wonder how vulnerable eg. Linux filesystem level encryption is to these kinds of attacks...
I want to see the response from sync.com on this, especially about
Unauthenticated Key Material
Unauthenticated Public Keys
The world changes once you realize why usually encryption is capped at AES256...
256 bit symmetric cryptography keys are a bit like picking one atom in the universe (10^80 atoms, or 100000000000000000000000000000000000000000000000000000000000000000000000000000000). Your opponent would have to test half of the atoms in the universe to have a reasonable chance of getting the right key.
That's generally understood to be not feasible.
https://www.schneier.com/blog/archives/2009/09/the_doghouse_...
It's more than that. Simply incrementing your way through a 256 bit counter is impossible by the thermodynamic cost alone.
Correct. Better to get into other forms of cryptography than pointlessly increase the numbers. We need to think more about PQ proofing.
Care to enlighten us? What did you realize?
It's too CPU heavy and your webservers crash under load would be my guess, for no added benefit [1] of course.
[1] https://security.stackexchange.com/questions/14068/why-most-...
Correct. Anything higher is an order of magnitude more computationally expensive to do for no real reasonable gain. Multiple layers of encryption get you there far enough. Better to dig deeper into other cryptography methods than try increase AES beyond 256. Its already rather insane how quickly decryption happens.
The sad state of E2E encryption for cloud storage is a big part of why I wrote mobiletto [1]. It supports transparent client-side encryption for S3, B2, local storage and more. Rekeying is easy- set up a new volume, mirror to it, then remove old volume.