If they aren't multitenant systems it doesn't make sense to compare them to the targets of this paper.
jszymborski 41 days 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.
traceroute66 41 days ago [-]
> 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.
jszymborski 41 days ago [-]
I understand now, thanks :)
megous 42 days 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...
Sat_P 41 days 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.
triyambakam 42 days 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 42 days ago [-]
I think Proton is more viewed as a honeypot
3np 41 days ago [-]
Which would make it all the more interesting to look at.
ziddoap 41 days ago [-]
I have not seen this take before, do you have any pointers to someone making this claim?
rettichschnidi 41 days ago [-]
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].
Doing crypto on the client side in JS is absolutely the correct way to do this if you want E2EE with a web client. You need to be careful about supply chain attacks etc.
> To me, this smells like Crypto AG
It's easy to throw around unsubstantiated, impossible to disprove theories.
devman0 41 days ago [-]
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?
stavros 41 days ago [-]
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.
akimbostrawman 37 days ago [-]
this can be mitigated by using a browser addon to calculate and verify the web js content is matching the hash in a public code repo. That is how CTemplar Mail does it.
I'm disappointed they haven't implemented something like this.
ranger_danger 41 days ago [-]
WASM? I have seen it used a lot for this.
protonprivacy 35 days ago [-]
We are not affiliated with Crypto AG. Our encryption occurs client-side, our cryptographic code is open source, and our tech can and has been independently verified.
andrewinardeer 41 days ago [-]
Is the suggestion that founders who have US affiliation are automatically in bed with three letter agencies?
justinclift 41 days ago [-]
If they're physically located in the US, they have no way to stop (legal) coercion by the TLAs yeah?
willis936 40 days ago [-]
How is this different than 90% of other VPN providers out there? The claim shouldn't be "Proton is a honeypot" but that "US VPNs are a honeypot".
bartbutler 34 days ago [-]
We aren't physically located in the US.
justinclift 30 days ago [-]
Who's the "we" in this context? :)
yieldcrv 41 days ago [-]
In account creation, requiring a phone number for “spam prevention” on Tor
There was some deanonymizing like that, phone or credit card
ranger_danger 41 days ago [-]
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.
gertop 40 days ago [-]
Knowing as little as legally possible about your customer is the actually smart move if your entire selling point is privacy.
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.
ranger_danger 40 days ago [-]
> Knowing as little as legally possible about your customer is the actually smart move if your entire selling point is privacy.
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.
akimbostrawman 37 days ago [-]
it is possible to get google captchas as verification on some nodes however it is rare and was easier in the past.
I'm disappointed that they haven't used there own captchas but maybe they will in the future.
bartbutler 34 days ago [-]
We (Proton) have had our own CAPTCHA for a year or more now.
thephyber 41 days ago [-]
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.
The link on that post is down. The domain seems to be bought out. Did you not even check the post before posting it?
triyambakam 41 days ago [-]
So what's the alternative?
create-username 41 days ago [-]
The alternative is to store Cryptomator vaults on any cloud. I’m looking forward for reading that proton drive allows cyberduck compatibility to manage Cryptomator vaults
opengears 41 days ago [-]
Selfhosting
MarcusE1W 40 days ago [-]
Actually I don't think self-hosting is a viable solution for many people. Most server hosts are not security experts. IT security is really hard due to the many possible attack vectors you have to be knowledgeable about. In this article they assume that an attacker has compromised a server and I don't see how a layman can keep a server safe if experts want to compromise it in the long term if you just follow the reccomend maintenance. One day you will slip up.
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.
dartos 41 days ago [-]
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
triyambakam 41 days ago [-]
Hmm, yeah that's true
traceroute66 41 days 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.
willis936 40 days 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.
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 41 days ago [-]
Angular
ThePhysicist 41 days 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.
tptacek 41 days 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.
traceroute66 41 days 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.
tptacek 41 days ago [-]
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.
fauxlister 39 days ago [-]
The paper itself seems not to agree with you: “Tresorit’s design is mostly unaffected by our attacks due to a comparably more thoughtful design and an appropriate choice of cryptographic primitives.”
tptacek 39 days ago [-]
They have a lot of attacks. Most of these systems are completely clownshoes. But Tresorit appears to be vulnerable to their most severe attack.
gertop 40 days ago [-]
> I wouldn't put my data on US jurisdiction servers no matter how much money you gave me.
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!
traceroute66 41 days ago [-]
Worth pointing out for balance that Tresorit are aware of the paper and have published a statement on their LinkedIn[1].
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.
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.
gertop 40 days 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.
curious about iCloud with Advanced Data Protection enabled
MichaelZuo 41 days 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.
java-man 42 days ago [-]
I want to see the response from sync.com on this, especially about
Unauthenticated Key Material
Unauthenticated Public Keys
attacks.
V__ 41 days 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.
cobbzilla 42 days 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.
> 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.)
cobbzilla 39 days 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.
CPAhem 41 days 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.
dropbox has been mentioned in the article and I think the author is drinking kool-aid and throwing random facts
kientuong114 41 days 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.
It's not an article, it's an academic paper, and Dropbox isn't one of the targets.
nonamepcbrand1 41 days ago [-]
[flagged]
nl 41 days ago [-]
I'm not 100% sure but I have a feeling that tptacek might know what E2EE is.
revendell_elf 41 days ago [-]
[dead]
42 days ago [-]
mr_toad 41 days 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.
tptacek 41 days 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.
paulgerhardt 41 days ago [-]
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.
cperciva 40 days ago [-]
I mean... tools, not policy, right? Tarsnap is whatever you want to make of it. :-)
eemil 41 days 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.
tjpnz 41 days 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.
willis936 40 days 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.
idle_zealot 41 days 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.
hansvm 41 days 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).
mprime1 41 days 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!
Someone said (wrongly) it’s impossible and I shared a popular project that does exactly that.
orf 38 days ago [-]
“Not backing up the same file twice” is not the same thing as deduplicating encrypted data, as encryption has no relevance there. You can do that with or without encryption.
RcouF1uZ4gsC 41 days ago [-]
Even 32 bytes of random data has an astronomically low chance to ever have a collision.
slac 41 days ago [-]
Google Drive has allowed for client side encryption since 2022... This papers first paragraph is false.
ranger_danger 41 days ago [-]
Only for enterprise workspace customers. rclone/cryptomator/etc. has always been possible with practically any solution though.
thinkingofthing 41 days ago [-]
Can you provide sources? I haven't been able to find the option for true E2EE
The world changes once you realize why usually encryption is capped at AES256...
oconnore 41 days 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.
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.
coppsilgold 41 days ago [-]
You can trivially modify the AES key schedule to have a key size of any length (ex. replace it with a hash function or a sponge construct) and have any number of increased rounds in the AES permutation. Performance impact will linearly scale with the number of rounds.
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...
ziddoap 40 days ago [-]
Hmm, not sure how this was supposed to change my world. I thought you had some secret cabal conspiracy or something to share.
[0] https://cryptomator.org/
[1] https://vgough.github.io/encfs/
[2] https://github.com/rfjakob/gocryptfs
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...
[3] https://en.wikipedia.org/wiki/Crypto_AG
[4] https://en.wikipedia.org/wiki/Operation_Rubicon
> 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.
[1] https://lemmygrad.ml/post/4177
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.
https://proton.me/support/increase-storage-space/
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.
https://manual.seafile.com/security/security_features/
[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.)
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!
https://www.borgbackup.org/
Parent was asking about deduping encrypted data.
Someone said (wrongly) it’s impossible and I shared a popular project that does exactly that.
https://support.google.com/a/answer/14326936
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...