End-to-End Encrypted Cloud Storage in the Wild: A Broken Ecosystem

by dogtype • 2 years ago

136 100 2 years ago

java-man• 2 years ago

I want to see the response from sync.com on this, especially about

  Unauthenticated Key Material

  Unauthenticated Public Keys

attacks.

iknowstuff2• 2 years ago

curious about iCloud with Advanced Data Protection enabled

MichaelZuo• 2 years ago

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.

megous• 2 years ago

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

cobbzilla2• 2 years ago

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.

[1] https://github.com/cobbzilla/mobiletto

gertop4• 2 years ago

Rekeying is easy- set up a new volume, mirror to it, then remove old volume.

Right, just have to transfer those 10TB every time a key needs to be rotated, no biggie!

I think that is the reason why most systems use two levels of keys (user keys encrypting a master key. Rotating means ditching the user keys, not the master.)

cobbzilla2• 2 years ago

Sure but at some point you need to rotate your master key. Copying is inevitable. At least your tooling can make it easy and reliable.

fguerraz• 2 years ago

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.

kientuong1142• 2 years ago

NextCloud has already been analyzed by some great people (https://eprint.iacr.org/2024/546).

xarope2• 2 years ago

seafile is open source (https://github.com/haiwen/seafile), or at least was, when I looked at it years ago. Definitely a concern when the paper mentioned an acknowledge of the protocol downgrade as of 29th April 2024, yet the latest version on the seafile github is dated feb 27.

gertop4• 2 years ago

Seafile shouldn't be recommended when discussing e2ee cloud solutions.

What seafile calls e2ee actually sends your password to the server (except on the desktop application, where actual e2ee happens).

They also don't encrypt any metadata such as filenames and hash of the unencrypted content. which might not seem like a big deal but it can accidentally leak sensitive information.

https://manual.seafile.com/security/security_features/

triyambakam3• 2 years ago

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

canadiantim• 2 years ago

I think Proton is more viewed as a honeypot

ziddoap3• 2 years ago

I have not seen this take before, do you have any pointers to someone making this claim?

triyambakam3• 2 years ago

So what's the alternative?

traceroute664• 2 years ago

I think Proton is more viewed as a honeypot

Honestly, this FUD goes round more often than the seasons.

As with most FUD, I'm still waiting for someone to prove it.

And no, I don't buy the "smells like crypto AG" FUD, because you could use that sort of FUD for any of the US-cloud providers ....

For example, when AWS says "trust us" in relation to their KMS or HSM services, can you, really ... eh eh eh .... how do you know KMS or HSM isn't just a software proxy that pretends to be what it is ? :)

The fact is that if you are going to use someone else's servers to do something for you. Whether that someone is Proton or AWS or anyone else. You are, by definition, forced to abstract away your trust boundaries.

3np• 2 years ago

Which would make it all the more interesting to look at.

willis9363• 2 years ago

I want to consider Proton, but they cap out their maximum storage very low with no option to increase. They're not really competing in this space because no one needs backup of only a few GB of data.

https://proton.me/support/increase-storage-space/

swijck4• 2 years ago

The world changes once you realize why usually encryption is capped at AES256...

oconnore• 2 years ago

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.

alwayslikethis• 2 years ago

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.

brokenmachine• 2 years ago

He could get lucky though. :-P

ziddoap3• 2 years ago

Care to enlighten us? What did you realize?

levkk• 2 years ago

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

ThePhysicist• 2 years ago

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.

tptacek7• 2 years ago

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.

traceroute664• 2 years ago

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.

traceroute664• 2 years ago

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

paulgerhardt• 2 years ago

My understanding was that Tarsnap was just fine and that was the preferred solution for Hacker News outside Dropbox.

vmfunction• 2 years ago

Or https://syncthing.net

tptacek7• 2 years ago

Tarsnap is a backup service, not an encrypted drive.

cperciva• 2 years ago

I mean... tools, not policy, right? Tarsnap is whatever you want to make of it. :-)

CPAhem• 2 years ago

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.

V__• 2 years ago

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.

nonamepcbrand1• 2 years ago

https://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

tptacek7• 2 years ago

It's not an article, it's an academic paper, and Dropbox isn't one of the targets.

kientuong1142• 2 years ago

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

jszymborski3• 2 years ago

I wonder how Cryptomator [0], EncFS [1] or gocryptfs [2] stacks up.

[0] https://cryptomator.org/

[1] https://vgough.github.io/encfs/

[2] https://github.com/rfjakob/gocryptfs

tptacek7• 2 years ago

If they aren't multitenant systems it doesn't make sense to compare them to the targets of this paper.

jszymborski3• 2 years ago

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.

mr_toad• 2 years ago

If you don’t trust your cloud provider to not look at your data, why would you trust them with encryption?

It’s not hard to encrypt it before you upload it.

tptacek7• 2 years ago

Because not having to trust the provider is the entire premise of these services, and without that premise, you might as well just store things in GDrive.

xarope2• 2 years ago

I 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?

0x073• 2 years ago

Angular

slac• 2 years ago

Google Drive has allowed for client side encryption since 2022... This papers first paragraph is false.

thinkingofthing• 2 years ago

Can you provide sources? I haven't been able to find the option for true E2EE

bertman• 2 years ago

https://workspace.google.com/blog/product-announcements/new-...

https://support.google.com/a/answer/14326936

ranger_danger5• 2 years ago

Only for enterprise workspace customers. rclone/cryptomator/etc. has always been possible with practically any solution though.

eemil• 2 years ago

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

idle_zealot• 2 years ago

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.

RcouF1uZ4gsC• 2 years ago

Even 32 bytes of random data has an astronomically low chance to ever have a collision.

hansvm• 2 years ago

If you can, you've effectively broken the encryption. Any scheme that takes random data and stores it in less space, when accounting for the overhead of the scheme itself, is astronomically unlikely to succeed by more than a few bits saved in any specific example (and on average across all such random streams cannot save space at all).

mprime12• 2 years ago

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/

tjpnz• 2 years ago

Double edged sword. Mega Upload were doing it and it was argued (successfully) in court that they therefore had knowledge of what they were hosting.

willis9363• 2 years ago

That's fine. We pay for storage. I'll pay extra to not have the host spy, sell, etc. my data.

Deduplication only really shines if most data is pirated copy data. In reality the vast majority of data is in fine details of high resolution photos and videos of completely uncorrelated images.

Sat_P• 2 years ago

I was using Boxcryptor with OneDrive for over 5 years and once they shut it down, I moved everything back to my local SSD. This had a number of advantages, the biggest one being that I could now use MacOS search to find files at lighting speed. I’ll never go back to cloud storage for files again due to latency. As a precaution, I now back up all of my data to an external HDD daily, then to a separate one on 1st of each month. Critical financial data is archived to a BluRay on the first day of each quarter.

End-to-End Encrypted Cloud Storage in the Wild: A Broken Ecosystem

Related Stories