How encrypted cloud storage works

The pipeline, simplified 1. You enter your password on your device. 2. A KDF (Argon2id) turns it into a master key. 3. For each file, a per-file key is generated locally. 4. The file is encrypted with XChaCha20-Poly1305 using that per-file key. 5. The per-file key is wrapped under your master key. 6. Ciphertext and wrapped key are uploaded.

What the server sees Opaque ciphertext. Wrapped keys. Account identifier. Sizes and timestamps. That is the minimal set required to deliver and bill the service.

What sharing looks like When you share a file with another user, your client wraps the per-file key under that user's public key (X25519 sealed box). The server transports the wrapped key but cannot decrypt it.

Why this is robust If the server is breached, the attacker holds ciphertext. If a court compels disclosure, the provider can only deliver ciphertext. If a staff member becomes malicious, they have no path to plaintext.

A concrete walkthrough When you upload a document, your browser generates a fresh symmetric key (XChaCha20-Poly1305), encrypts the file in memory, and only then sends the ciphertext to the server. The server stores opaque bytes. The symmetric key itself is wrapped using your account's public key (X25519 sealed box) so only your private key — which never leaves your device — can unwrap it.

What the server can and cannot see It sees the ciphertext, its byte length, the upload timestamp, and the user account it belongs to. It does not see filenames (those are encrypted too), folder structures, content, previews, or thumbnails. Metadata leakage is reduced to what is strictly necessary for delivery.

Why this matters in practice A breach of the storage layer leaks opaque bytes. A subpoena returns opaque bytes. An internal AI pipeline finds opaque bytes. The architectural guarantee is the same in every scenario: no plaintext, no recovery, no exception.