Live data from Hacker News

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

brokencloudstorage.info

61–70 of 105 posts

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

#61

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

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

#62

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

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

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

#63

Earlier quoted context omitted.

So what's the alternative?

Selfhosting

If that 3+ TB attack CF just mitigated starts aiming at the entire ipv4 range (probably more spread out and cyclical), self hosting could die :(

At least anything on UDP

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

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

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

#65
post #64

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.

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.

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

#66
post #64

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.

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.

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

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

#67
post #64

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.

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.

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

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

#68
post #36

Earlier quoted context omitted.

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

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_favourite_tool pre-encrypt route is simply not feasable or scalable and would be hell on earth to manage and maintain.

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

#69
post #64

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.

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.

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

#70
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.
Post reply on HN