Zero-knowledge encryption

The client encrypts, then uploads ciphertext. AWS describes the mechanical version as client-side encryption: the SDK encrypts the object before the PUT, and the bucket stores that ciphertext. NIST SP 800-57's point applies directly. Whoever holds the key can read. If the provider does not hold it, the provider cannot.

The phrase is not an RFC, and products use it loosely. Some mean the provider cannot decrypt. Some mean the provider cannot see filenames either. Some mean a password derives the key and there is no recovery. Those are different promises. A service that can reset your password and still open the file holds a recovery path. That is not zero knowledge. A service that cannot reset the password will lose the file when the user loses the password. That is the trade.

A journalist uploads a 2 GB archive through a client that derives a key from a passphrase and encrypts before the POST. The provider's disk and its backups hold ciphertext. A subpoena for the object produces bytes the provider cannot open. Transit encryption still matters on the way up, but the provider is no longer the end of the trust. If the same app encrypts in the browser with a key fetched from the provider's API, the provider held the key at least once. The label on the pricing page does not settle which of those two designs is running.

This is stronger than server-side encryption at rest, and it is not a substitute for access control on the ciphertext. Anyone who gets the ciphertext and the passphrase reads the file. Anyone who gets only the ciphertext does not. Sharing means sharing the passphrase or a wrapped key out of band. A public link to a zero-knowledge blob hands out ciphertext. It does not hand out the file unless the key is in the URL, in which case the provider's logs may have captured the key.