But perhaps I've misunderstood you.
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.
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...
[1] https://proton.me/about/team
[2] https://steigerlegal.ch/2019/07/27/protonmail-transparenzber...
> To me, this smells like Crypto AG
It's easy to throw around unsubstantiated, impossible to disprove theories.
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
The bridge looks good, though it seems really shady that it's not open source. I'd expect it to definitely be open.
I'm disappointed they haven't implemented something like this.
There was some deanonymizing like that, phone or credit card
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.
Yes I agree, but Proton also provides paid services and it is often the law that you must retain certain records in cases of audits, fraud etc., so there is some necessary KYC in that sense, but perhaps you're right in that they could keep less information, possibly at the cost of increased spam and decreased reputation though, so I understand the struggle.
> But then why not impose a captcha when sending emails
I suppose you could, but perhaps they weighed that possibility against it turning people off to using the service entirely? Not sure.
> When it comes to mullvad I'm not sure what you're trying to say
I was not trying to imply any of those things, just pointing out that companies still have to answer to law enforcement sometimes, that they are not immune from the laws of their country... because I have seen that some people who are staunch privacy enthusiasts seem to think companies have the luxury or practical ability (without detriment to their business) to simply not know their customer at all, and I don't think that is often the case. There is also a balance between simplicity and privacy. If you want anonymous payments that's fine, but crypto isn't as easy to use as a credit card. But if you handle credit cards, you must keep some data by law usually. Things like that.
And some people might just want to sell your info to advertisers or data brokers, there's always that.
I'm disappointed that they haven't used there own captchas but maybe they will in the future.
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.
You might get a security related update late, did not hear about the last breach and are not aware how that relates to you, all sorts of scenarios. The only way to make it much more difficult to be compromised is if you don't connect your self-hosted cloud solution to the internet. But then it's not a really a cloud solution anymore.
And that's before you have to consider that not everyone has the knowledge, time, interest to self host.
At least anything on UDP
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.
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.
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.
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!
[1] https://www.linkedin.com/posts/tresorit_end-to-end-encrypted...
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.
Unauthenticated Key Material
Unauthenticated Public Keys
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.)
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.
dropbox has been mentioned in the article and I think the author is drinking kool-aid and throwing random facts
[1] https://blog.dropbox.com/topics/company/new-solutions-to-sec...
It’s not hard to encrypt it before you upload it.
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.
My bookmark archive is 10TB but deduped on-disk size is 100GB because most files are the same across backups!
Parent was asking about deduping encrypted data.
Someone said (wrongly) it’s impossible and I shared a popular project that does exactly that.
That's generally understood to be not feasible.
It's more than that. Simply incrementing your way through a 256 bit counter is impossible by the thermodynamic cost alone.
[1] https://security.stackexchange.com/questions/14068/why-most-...
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...