[HN Gopher] End-to-End Encrypted Cloud Storage in the Wild: A Br...
___________________________________________________________________
End-to-End Encrypted Cloud Storage in the Wild: A Broken Ecosystem
Author : dogtype
Score : 71 points
Date : 2024-10-10 13:00 UTC (10 hours ago)
(HTM) web link (brokencloudstorage.info)
(TXT) w3m dump (brokencloudstorage.info)
| java-man wrote:
| I want to see the response from sync.com on this, especially
| about Unauthenticated Key Material
| Unauthenticated Public Keys
|
| attacks.
| iknowstuff wrote:
| curious about iCloud with Advanced Data Protection enabled
| MichaelZuo wrote:
| 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 wrote:
| 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...
| cobbzilla wrote:
| 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
| fguerraz wrote:
| 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.
| kientuong114 wrote:
| NextCloud has already been analyzed by some great people
| (https://eprint.iacr.org/2024/546).
| triyambakam wrote:
| 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 wrote:
| I think Proton is more viewed as a honeypot
| ziddoap wrote:
| I have not seen this take before, do you have any pointers to
| someone making this claim?
| thephyber wrote:
| 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
| rettichschnidi wrote:
| Founders with US affiliation/physicist creating crypto
| products [1], faulty claims how the relevant Swiss law
| (BUPF) applies to them [2], doing crypto in JavaScript on
| the client side, etc. To me, this smells like Crypto AG
| [3][4].
|
| [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
| andrewinardeer wrote:
| Is the suggestion that founders who have US affiliation
| are automatically in bed with three letter agencies?
| triyambakam wrote:
| So what's the alternative?
| swijck wrote:
| The world changes once you realize why usually encryption is
| capped at AES256...
| oconnore wrote:
| 256 bit symmetric cryptography keys are a bit like picking one
| atom in the universe (10^80 atoms, or 1000000000000000000000000
| 00000000000000000000000000000000000000000000000000000000). 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 wrote:
| 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.
| ziddoap wrote:
| Care to enlighten us? What did you realize?
| levkk wrote:
| 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 wrote:
| 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.
| paulgerhardt wrote:
| My understanding was that Tarsnap was just fine and that was the
| preferred solution for Hacker News outside Dropbox.
| vmfunction wrote:
| Or https://syncthing.net
| CPAhem wrote:
| 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__ wrote:
| 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.
___________________________________________________________________
(page generated 2024-10-10 23:00 UTC)