End-to-end encrypted photo storage for maximum privacy
What end-to-end encryption means for a photo library, how it differs from at-rest encryption, and the operational details that decide whether it works in daily use.
Try it in one click.
Three private surfaces. Same zero-knowledge architecture.
End-to-end, applied to a gallery End-to-end encryption means the content is encrypted on the sending device and decrypted only on the receiving device. For a photo library the "receiver" is usually you, on another device — so the model becomes: sealed on capture, opened only on devices holding your keys.
The provider is a relay for ciphertext. That is the entire design goal.
The properties that must hold - **Local key derivation.** Argon2id over your passphrase, on the device, with parameters tuned to be expensive for attackers. - **Per-item content keys.** A fresh random key per photo or video, so one compromise never generalises. - **Authenticated encryption.** XChaCha20-Poly1305 provides confidentiality plus tamper detection; a modified ciphertext fails to open. - **Asymmetric wrapping for sharing.** X25519 seals a copy of the item key for each recipient, without a shared secret ever passing through the server. - **Encrypted metadata.** Names, albums, EXIF. - **No escrow.** No second copy of your key held "just in case".
The operational details that decide adoption Cryptography is the easy half. These are the parts that make or break daily use:
Thumbnails. Generated on the device and stored sealed, or a large album is unusable. Cached locally so scrolling stays instant.
Large videos. Downloading 300 MB before playback is not acceptable. Encrypted streaming decrypts chunk by chunk as you watch, with seek support.
Interrupted uploads. Mobile networks fail. Uploads must checkpoint and resume from where they stopped rather than restarting.
Search. Blind-index HMAC tags computed on the device let you find items without a readable server index.
Multiple devices. Adding a device must wrap your keys for it without ever exposing them to the server.
Offline. Recently viewed items should be available with no network, decrypted from a local encrypted cache.
Sharing without breaking the model Two mechanisms cover almost every case:
- Per-recipient wrapping for people with an account: their device holds a sealed copy of the key; removing them rotates it.
- Fragment links for people without one: key material sits after the `#`, which browsers never transmit, protected by a passphrase and a hard expiry of at most 24 hours.
Recovery, stated plainly There is no provider-side reset. Instead, a recovery kit generated on your device — a high-entropy key you print or store offline that can unwrap your master key. Generate it at signup, store it away from your devices, and test it once.
What you should still expect to be visible Object count, approximate sizes, timestamps, connection metadata and billing information. Any provider claiming to see literally nothing is overstating; storage systems know what they store, even when they cannot read it.
DRIVUNO's implementation, in one paragraph Argon2id key derivation on the device, per-item XChaCha20-Poly1305 payloads, X25519 wrapping for members and share recipients, encrypted file names, on-device thumbnails, encrypted video streaming with seek, resumable uploads with integrity verification, blind-index search, passphrase-gated 24-hour maximum links, and an offline recovery kit. The server stores ciphertext and wrapped keys, and nothing that can unwrap them.
Try it in one click.
Three private surfaces. Same zero-knowledge architecture.