End-to-End Encrypted Cloud Storage in the Wild: A Broken Ecosystem

Original Article ↗ Hacker News Discussion ↗

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.