Encrypted photo storage: how zero-knowledge protects your personal photos
A clear, technical explanation of how client-side encryption protects private personal media — key derivation, per-item keys, encrypted metadata and safe sharing.
Try it in one click.
Three private surfaces. Same zero-knowledge architecture.
Three different things are called "encrypted" When a photo service says "encrypted", it can mean one of three architectures:
- In transit. TLS protects the upload. The provider decrypts on arrival.
- At rest. Disk-level encryption protects storage hardware. The provider holds the key.
- End-to-end / zero-knowledge. The image is encrypted on your device with a key the provider never receives.
Only the third protects a photo from the provider itself. The first two protect it from network eavesdroppers and from someone stealing a drive out of a datacenter — both real threats, neither the one people mean when they ask "can anyone see my private photos?".
The chain, step by step A well-built zero-knowledge photo vault does the following on your device:
1. Derive a master key. Your passphrase is stretched with Argon2id, a memory-hard KDF chosen specifically to make brute-force attacks expensive even with GPUs.
2. Generate a per-item key. Each photo gets a fresh random symmetric key. Reusing one key across a library would mean one compromise loses everything.
3. Seal the payload. The image is encrypted with XChaCha20-Poly1305, an authenticated cipher: it provides confidentiality and tamper detection, so a modified ciphertext fails to open rather than decrypting into garbage.
4. Wrap the key. The per-item key is encrypted ("wrapped") under your master key, and — for shared albums — under each recipient's X25519 public key.
5. Upload ciphertext only. The server stores the sealed payload and the wrapped keys. It holds no material that can unwrap them.
Metadata is content This is where many "private" galleries quietly leak. A photo named `scan-passport-2026.jpg` in an album named "Medical" tells a story even if the pixels are sealed. A serious design encrypts:
- file names and album names
- EXIF, including GPS coordinates and device identifiers
- thumbnails (generated locally, then sealed like any other item)
What necessarily remains visible to any storage provider: that an object exists, roughly how large it is, and when it was written.
Search without a readable server If the server cannot read the file name, how do you find anything? With blind indexes. The client computes an HMAC of each search token under a key only you hold and stores the resulting opaque tags. When you search, your device computes the same tags and asks the server which objects carry them. The server matches meaningless strings and learns nothing about the query.
Sharing without handing over the key A shareable link needs to carry key material without letting the host learn it. The standard technique uses the URL fragment — everything after `#` — which browsers never transmit in the HTTP request. Add a passphrase gate, a hard expiry and a view cap, and you have a link that is useful for a day and inert afterwards.
DRIVUNO caps every public link at 24 hours maximum, on purpose: an indefinite link is an indefinite liability.
Recovery is the honest hard part No provider-side key means no provider-side reset. The workable answer is a recovery kit: a high-entropy key, generated on your device, printed or stored offline, capable of unwrapping your master key. It moves the risk from "someone else can read my photos" to "I must not lose this piece of paper" — a risk you can control.
What this buys you - Automated content analysis cannot run on your library. - A breach of the storage layer exposes ciphertext. - A legal request answered honestly returns ciphertext. - Sharing has a fuse instead of a permanent public URL.
That is the whole promise, and it is deliberately narrow: your provider stops being a party that can read your personal photos.
Try it in one click.
Three private surfaces. Same zero-knowledge architecture.