Earlier quoted context omitted.
I guess they have this for local email decryption: https://proton.me/mail/bridge idk if they have anything like that for their other products like calendar or file storage Presumably if you stick to mobile apps you won't be using JavaScript served by their server? Unless they're just html wrappers
Yeah, apps are generally OK, unless they're webviews, as you say. The bridge looks good, though it seems really shady that it's not open source. I'd expect it to definitely be open.
End-to-End Encrypted Cloud Storage in the Wild: A Broken Ecosystem
71–80 of 105 posts
Re: End-to-End Encrypted Cloud Storage in the Wild: A Broken Ecosystem
#72Earlier quoted context omitted.
I suppose I meant for the specific use case where you store and sync the encrypted file systems with cloud providers like e.g. Dropbox or pCloud. But perhaps I've misunderstood you.
> I suppose I meant for the specific use case where You're missing the point. Anybody can download $insert_name_of_your_favourite_software and use that to encrypt data before uploading to cloud storage. The point here is the discussion about multi-tenant cloud-based solutions. You know, the sort of thing you use in a work environment when you share documents with your colleagues. In that context, the DIY $my_favourit…
I understand now, thanks :)
Re: End-to-End Encrypted Cloud Storage in the Wild: A Broken Ecosystem
#73Earlier quoted context omitted.
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…
I really don't care about this jurisdiction stuff; I'm just here to talk about the cryptography, which, in the case of Tresorit, is not great.
Re: End-to-End Encrypted Cloud Storage in the Wild: A Broken Ecosystem
#74One downside to encryption, is it prevents the server operator from doing any deduplication (file or block level) on their end. Maybe one reason why cloud providers aren't pushing it that heavily. Especially the big players, since more data = more duplication = more efficient deduplication.
Is that true? Couldn't you run dedupe on blocks of encrypted files? I assume there would be fewer duplicate blocks compared to the cleartext, but if you have a bunch of blocks full of random bits there are bound to be repeats with a large enough number of blocks.
Indeed. Borg for example is e2e but able to dedupe.
My bookmark archive is 10TB but deduped on-disk size is 100GB because most files are the same across backups!
Re: End-to-End Encrypted Cloud Storage in the Wild: A Broken Ecosystem
#75Nice 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…
Worth pointing out for balance that Tresorit are aware of the paper and have published a statement on their LinkedIn[1].
[1] https://www.linkedin.com/posts/tresorit_end-to-end-encrypted...
Re: End-to-End Encrypted Cloud Storage in the Wild: A Broken Ecosystem
#76Earlier quoted context omitted.
How else would you do client side crypto for a website if not with JavaScript, isn't that kind of the point of how Proton does E2EE?
Crypto for websites is completely broken (because the server can serve you whatever it wants), so doing crypto for websites at all is suspicious.
It's not "broken", please don't spread FUD. It's a whole lot more transparent than doing it on the server side. Client code can be inspected and publicly audited, and many times you can save/cache it so that it doesn't change. Also opens up the possibility for third party standalone apps that don't change often.
Re: End-to-End Encrypted Cloud Storage in the Wild: A Broken Ecosystem
#77Earlier quoted context omitted.
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... [3] https://en.wikipedia.org/wiki/Crypto_AG [4] https://en.wikipedia.org/wiki/Operation…
How else would you do client side crypto for a website if not with JavaScript, isn't that kind of the point of how Proton does E2EE?
WASM? I have seen it used a lot for this.
Re: End-to-End Encrypted Cloud Storage in the Wild: A Broken Ecosystem
#78Earlier quoted context omitted.
I have not seen this take before, do you have any pointers to someone making this claim?
In account creation, requiring a phone number for “spam prevention” on Tor There was some deanonymizing like that, phone or credit card
KYC for a business is the smart legal move IMO whether it's technically required or not. Yes Proton is required to cooperate with law enforcement and government requests. Mullvad has been raided and Tutanota servers have been seized before too. Nobody is going to jail for you.
Re: End-to-End Encrypted Cloud Storage in the Wild: A Broken Ecosystem
#79Earlier quoted context omitted.
Is that true? Couldn't you run dedupe on blocks of encrypted files? I assume there would be fewer duplicate blocks compared to the cleartext, but if you have a bunch of blocks full of random bits there are bound to be repeats with a large enough number of blocks.
Indeed. Borg for example is e2e but able to dedupe. My bookmark archive is 10TB but deduped on-disk size is 100GB because most files are the same across backups! https://www.borgbackup.org/
That’s not the same thing at all.
Re: End-to-End Encrypted Cloud Storage in the Wild: A Broken Ecosystem
#80Google Drive has allowed for client side encryption since 2022... This papers first paragraph is false.
Only for enterprise workspace customers. rclone/cryptomator/etc. has always been possible with practically any solution though.