My understanding was that Tarsnap was just fine and that was the preferred solution for Hacker News outside Dropbox.
Tarsnap is a backup service, not an encrypted drive.
End-to-End Encrypted Cloud Storage in the Wild: A Broken Ecosystem
81–90 of 105 posts
Re: End-to-End Encrypted Cloud Storage in the Wild: A Broken Ecosystem
#82Earlier 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.
Re: End-to-End Encrypted Cloud Storage in the Wild: A Broken Ecosystem
#83Earlier quoted context omitted.
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.
Mail providers aren't bound to specific KYC regulation, proton could simply collect... Nothing. But they still do, why? The only legitimate reason they've given is to prevent spam. Fair enough, spammers using them will impact all users. But then why not impose a captcha when sending emails until you provide/validate your phone number? Possibly laziness, possibly complacency, possibly because it's a honeypot.
When it comes to mullvad I'm not sure what you're trying to say? That Proton collecting personally identifiable information will prevent a raid/downtime? Feels like wishful thinking. Or are you suggesting that mullvad gave personal info to the police? Because they didn't. They couldn't. BECAUSE THEY DON'T FORCE YOU TO PROVIDE ANY.
Re: End-to-End Encrypted Cloud Storage in the Wild: A Broken Ecosystem
#84It'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.
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.
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.
Re: End-to-End Encrypted Cloud Storage in the Wild: A Broken Ecosystem
#85Earlier 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…
Just to be clear: tresorit's storage provider is American. As of 2024 3 of the geographical locations they offer are part of the five eyes. 3 more have data sharing agreements with the US. which leaves three locations, that aren't the default and you need Business+ to switch to another.
I hope you made sure that your data is indeed stored in Switzerland or the UAE!
Re: End-to-End Encrypted Cloud Storage in the Wild: A Broken Ecosystem
#86The 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
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.)
Re: End-to-End Encrypted Cloud Storage in the Wild: A Broken Ecosystem
#87Earlier quoted context omitted.
I have not seen this take before, do you have any pointers to someone making this claim?
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. [1] https://lemmygrad.ml/post/4177
Re: End-to-End Encrypted Cloud Storage in the Wild: A Broken Ecosystem
#88Earlier quoted context omitted.
Is the suggestion that founders who have US affiliation are automatically in bed with three letter agencies?
If they're physically located in the US, they have no way to stop (legal) coercion by the TLAs yeah?
Re: End-to-End Encrypted Cloud Storage in the Wild: A Broken Ecosystem
#89Hmm, 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
Re: End-to-End Encrypted Cloud Storage in the Wild: A Broken Ecosystem
#90One 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.
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.