Educational
Encryption Explained
A guide for people who don't write cryptography for a living. Read this once and you'll understand exactly what DRIVUNO is doing — and why it matters.
1 · The two models
Most clouds use server-side encryption: the provider encrypts your files on their servers using keys they manage. It's better than nothing, but the provider holds both the lock and the key.
DRIVUNO uses client-side encryption: your device encrypts files before they leave it, with keys derived from a password only you know. The provider only ever sees scrambled bytes.
2 · What “zero-knowledge” really means
Zero-knowledge is a property of the system, not a marketing word. It means we have no technical way to read user content, even with full administrative access to our own infrastructure. Not “we promise not to look” — “we built it so we cannot look.”
3 · Why encryption before upload matters
4 · Recovery keys, and why they matter
Because we cannot read your password, we cannot reset it. To prevent permanent lockout, you can set up recovery factors: a Recovery Key (a string you write down), a secondary email, and SMS. Each factor independently wraps your master key on your device — never on our server.
5 · Large files: streaming encryption
A file that doesn't fit comfortably in memory can't be encrypted as one block without buffering the whole thing first. DRIVUNO instead uses a streaming AEAD construction: the file is split into chunks, and each chunk is encrypted and authenticated as part of a single continuous stream tied to one file key. Chunks are bound to their position, so an attacker cannot reorder, drop, or splice chunks without detection, and a final marker confirms the stream wasn't truncated.
This lets your browser encrypt and upload a large file progressively — and, on the way back down, decrypt and display it progressively too — without ever holding the full plaintext or ciphertext in memory at once. The same chunking makes uploads resumable: if a connection drops partway through, upload continues from the next chunk instead of starting over or re-exposing already-encrypted data.
6 · Searching without a plaintext index
Search needs an index, but a plaintext index of your filenames or message subjects would defeat the point of encrypting them. DRIVUNO instead computes a blind-index: an HMAC over normalized search terms, keyed by a value derived from your master key. The server stores only these opaque HMAC tags and can match a search query's tag against them — it never sees the underlying text, and the tags cannot be reversed back into words.
7 · Share passwords: a proof, not a stored secret
When you add an optional password to a public share, that password is never sent to the server in a form it could reuse. Your browser derives a verification proof from the password using Argon2id — the same slow, memory-hard function used for your account password — and only that proof is checked server-side. The password itself, and the key it derives to unwrap the share, stay local to the browser session.
8 · Recovery factors wrap, they never escrow
Every recovery factor — a Recovery Key, a secondary email or SMS code — works the same way: it wraps (encrypts) a copy of your master key on your device, producing a sealed envelope the server stores. None of these factors gives the server the master key itself, and none of them is a copy kept "in escrow" for support to use. Losing a factor means losing that one path back into your account, not handing anyone a spare key.
9 · Backups leave already sealed
Backup snapshots are encrypted before they leave our operating perimeter, using the same client-derived key material as everything else — a backup provider or storage region never receives anything more readable than what our own servers hold.
10 · The cryptographic primitives
- Argon2id — turns your password into a strong key, slowly enough to defeat brute force.
- XChaCha20-Poly1305 — encrypts your file bytes and detects any tampering.
- X25519 — lets us seal a file key for a specific recipient, including future shares.
- Ed25519 — signs share manifests so a tampered link is detected, not silently followed.
- SHA-256 — fingerprints the ciphertext, so we verify before decrypting.
All standard, peer-reviewed primitives. No homebrew cryptography.
Want the implementation detail? Read the architecture page or the whitepaper.