Encryption choices

Choose who holds the keys, down to a setup where we read nothing. Mix choices per bucket (a default) or per file (on upload). Placement, retention, receipts and tenancy work under all of them.

	Who holds the key	Can Permafrost read it?	Use it when
Your encryption	You, on your side	No. It only receives ciphertext verifiable	Your threat model includes the storage operator
Your key service	Your key service, on a dedicated deployment (on request)	Only while serving a request you authorised; revoking cuts it off completely our statement	You want server-side features, but the keys stay yours
Deployment keys (default)	The deployment	Yes	You want the simplest setup

TLS protects data in transit under every choice.

Your encryption: we can’t read it

Encrypt before upload. You still get receipts (the fingerprint of what was stored), placement, retention and tenancy. Leaving is complete: your ciphertext on Walrus and your keys are all you need. Destroy the key and the data is gone for everyone.

You give up server-side reads of content: range reads inside an encrypted file (unless your format supports them), and custody, which needs the deployment to hold the key it destroys.

Your key service

A dedicated deployment encrypts with a key service you run; the master key never leaves your control. Set up per deployment, on request.

• Every read asks your key service. Every use shows in your logs.
• Revoke and stored data is unreadable to the deployment at once, Walrus copies included. our statement
• Back it up. If it loses its keys, every object under them is unreadable, and we can’t recover them.
• A bucket default under your key service is enforced. A request for anything weaker is refused, not silently accepted.
• Receipts carry a salted fingerprint by default, checkable only by someone you give the salt.

Deployment keys (default)

Every upload is encrypted at rest per tenant, no header needed: single objects, and each part of a multipart upload as it lands. Walrus and the deployment’s disk see only ciphertext of what is written now; multipart uploads begun before this release, and multipart objects stored before it, stay as they were our statement. The deployment holds the keys, so its operator is in the trust path.

Receipts carry a salted fingerprint of the file you sent by default, checkable by anyone you give the file and its salt. A multipart upload’s posture is decided once, at CreateMultipartUpload, for all its parts; its receipt says encrypted and keeps the sizes of the file you sent.