End-to-End Encrypted Cloud Storage in the Wild: A Broken Ecosystem
End-to-end encrypted cloud storage services are coming under scrutiny for design flaws that let compromised servers manipulate keys, metadata, and shared folders, undermining their core promise that providers cannot access user data. Commenters weigh trade-offs between commercial E2EE products, open-source tools, and self-hosting, noting usability, key-rotation complexity, jurisdictional trust issues, and the limits of browser-based cryptography. Many conclude that layering independent client-side encryption (e.g., tar + encrypt, Cryptomator-style vaults) on top of generic cloud storage is currently more trustworthy than relying solely on built-in “zero-knowledge” offerings.
Overall reaction to the paper
- Many see the paper as confirming that commercial “zero knowledge” / E2EE storage is often fragile, especially around key authentication and metadata.
- Some are surprised how easy it is to attack structures (file metadata, chunk mapping) once the server is compromised.
- A recurring takeaway: if you truly care, encrypt/sign large blobs yourself (e.g., tar + encrypt) before using any cloud.
Provider‑specific discussion
- Sync.com: interest in how it will respond to unauthenticated key/public key issues raised in the paper.
- Apple iCloud ADP: curiosity about its security; some distrust due to reported silent data corruption in Photos.
- Tresorit: praised for relatively strong design and Linux support, but others highlight a “game‑over” vulnerability around server‑controlled public keys and sharing. Debate over how severe this is and whether real‑world sharing requires some server mediation.
- Nextcloud / Seafile: some wish the paper covered more open‑source options; others note Nextcloud has a separate analysis and criticize Seafile’s E2EE design (password sent to server, unencrypted metadata).
- Dropbox and Google Drive: mentioned that Dropbox Teams E2EE and Google Workspace client‑side encryption are recent/enterprise‑only and weren’t fully analyzed.
Proton ecosystem and honeypot debate
- Some rely heavily on Proton services and wish the paper had evaluated Proton Drive.
- Others repeat a “honeypot” meme, citing founders’ US links, Swiss law interpretations, JS crypto, and KYC/phone checks.
- Counter‑arguments: accusations are called FUD without concrete evidence; Proton staff respond that crypto is client‑side, open source, and independently verifiable; bridge app is open source.
- Disagreement over whether client‑side JS crypto and web‑based E2EE are fundamentally flawed or acceptable with proper auditing and caching.
Self‑hosting vs managed cloud
- Self‑hosting is proposed as an alternative, but several commenters argue it’s unrealistic for most users due to operational security, patching, and DDoS risks.
- Some suggest a hybrid approach: use generic cloud storage plus independent client‑side tools (e.g., Cryptomator vaults).
Standalone crypto tools and designs
- Mentioned tools: mobiletto (multi‑backend encrypted storage), Tarsnap, Syncthing, Syncdocs, Cryptomator, EncFS, gocryptfs, Borg.
- For key rotation, mirroring data to a new volume is seen as simple but expensive at multi‑TB scale; justification for layered key hierarchies.
- Discussion around AES‑256: consensus that 256‑bit symmetric keys are already overkill; higher sizes bring performance cost without realistic benefit; quantum resistance concerns center more on other primitives than AES.
Metadata, deduplication, and usability
- Unencrypted metadata (filenames, hashes) is flagged as a privacy leak in some systems.
- E2EE complicates server‑side deduplication; some argue that’s an acceptable cost, others note legal risks when providers dedupe plaintext.
- Several users ultimately favor local storage plus backups for speed and simplicity, treating cloud as optional or as storage for pre‑encrypted blobs only.