Earlier quoted context omitted.
It's not an article, it's an academic paper, and Dropbox isn't one of the targets.
[flagged]
I'm not 100% sure but I have a feeling that tptacek might know what E2EE is.
End-to-End Encrypted Cloud Storage in the Wild: A Broken Ecosystem
51–60 of 105 posts
Re: End-to-End Encrypted Cloud Storage in the Wild: A Broken Ecosystem
#52Earlier quoted context omitted.
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.
You can trivially modify the AES key schedule to have a key size of any length (ex. replace it with a hash function or a sponge construct) and have any number of increased rounds in the AES permutation. Performance impact will linearly scale with the number of rounds.
You can even have no key schedule at all and just make your AES key size in bits = 128 * num_of_rounds. This doesn't mean that the bruteforce complexity is going to be that high but that would hardly matter...
Re: End-to-End Encrypted Cloud Storage in the Wild: A Broken Ecosystem
#53Re: End-to-End Encrypted Cloud Storage in the Wild: A Broken Ecosystem
#54Google Drive has allowed for client side encryption since 2022... This papers first paragraph is false.
Re: End-to-End Encrypted Cloud Storage in the Wild: A Broken Ecosystem
#55I like the way you can use the tabs to check the results of each reviewed cloud storage service, and the exposition on each. Anybody know what the authors used to create this website? Custom built, or a templated version?
Angular
Re: End-to-End Encrypted Cloud Storage in the Wild: A Broken Ecosystem
#56https://dropbox.tech/security/end-to-end-encryption-for-drop... dropbox has been mentioned in the article and I think the author is drinking kool-aid and throwing random facts
Dropbox introduced this feature in April 2024 [1]. The CCS deadline was just a couple of days later; there was no chance of analyzing it meaningfully before then.
[1] https://blog.dropbox.com/topics/company/new-solutions-to-sec...
Re: End-to-End Encrypted Cloud Storage in the Wild: A Broken Ecosystem
#57Re: End-to-End Encrypted Cloud Storage in the Wild: A Broken Ecosystem
#58Google Drive has allowed for client side encryption since 2022... This papers first paragraph is false.
Can you provide sources? I haven't been able to find the option for true E2EE
Re: End-to-End Encrypted Cloud Storage in the Wild: A Broken Ecosystem
#59Google Drive has allowed for client side encryption since 2022... This papers first paragraph is false.
Can you provide sources? I haven't been able to find the option for true E2EE
Re: End-to-End Encrypted Cloud Storage in the Wild: A Broken Ecosystem
#60Nice 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…
Tresorit had a game-over vulnerability: public keys aren't meaningfully authenticated (the server can forge keys; the CA the paper discusses is operated by the service ) and any attempt to share a directory allows the server to share that directory with itself.
> Tresorit had a game-over vulnerability:
I would still (for now, at least) trust Tresorit over any of the US jurisdiction services. I wouldn't put my data on US jurisdiction servers no matter how much money you gave me.
I am, for now, tempted to say we should get a detailed explanation from Tresorit before jumping to conclusions.
It seems to me the author of the website made many assumptions, it is not clear if they entered into any sort of meaningful dialogue before publishing.
> any attempt to share a directory allows the server to share that directory with itself
Surely this is by definition required ?
If you wish to share a file or a directory with somebody external from your organisation via a simple link. How, exactly, do you envisage that happening without granting the Tresorit server permission to be the intermediary ?
Sure, you could, theoretically, mandate those third-party people to install software on their devices, or to register an account or whatever. But let's face it, in the real world, if you want to share a file or directory as a one-off with someone ? And forcing people to do extra steps for a one-off share is just introducing friction. Also some people can't install random software on their computers due to corporate policies.