Reference architecture

Security Architecture

Read this if you want to understand exactly how a DRIVUNO file moves from your screen to encrypted storage — and back — without our servers ever holding a usable key.

The trust boundary

Everything sensitive happens on one side of a clear line: your device. The server holds ciphertext and routing metadata, and nothing else useful to an attacker.

Inside the boundary
Your device only
  • • Your password (entered, never transmitted)
  • • Argon2id master key derivation
  • • Per-file XChaCha20-Poly1305 keys
  • • X25519 share key pairs (private half)
  • • Recovery Key (you write it down)
Outside the boundary
What the server holds
  • • Encrypted file blobs (opaque ciphertext)
  • • Sealed key envelopes (encrypted with your public key)
  • • Routing metadata: owner ID, parent ID, size
  • • Operational logs (no content, audit-only)
  • • Account record (email, settings, hashed identifiers)

1 · Upload flow

From file picker to encrypted storage
  1. 1You unlock your vault. Your password is run through Argon2id on your device to derive a master key. The password and master key never leave the browser tab.
  2. 2For each file, the browser generates a fresh random 256-bit file key.
  3. 3The browser encrypts the file with XChaCha20-Poly1305 using that file key. The output is opaque ciphertext plus an authentication tag.
  4. 4The file key is sealed against your account's public key (X25519 + libsodium sealed box). Only your master key can unwrap it.
  5. 5The browser uploads the ciphertext, the sealed envelope, and minimal routing metadata. The server stores all three but never holds a usable key.
  6. 6On download, the browser fetches the ciphertext and the sealed envelope, unwraps the file key locally, verifies the ciphertext SHA-256 hash, and decrypts in memory.

2 · Sharing flow

Zero-knowledge public share links
  1. 1You generate a share. The browser creates an ephemeral X25519 key pair specifically for this share.
  2. 2The file key is sealed against the share's public key. The sealed envelope is stored on the server.
  3. 3The share's private key is base64-encoded and placed in the URL fragment (after #). Browsers never transmit URL fragments to servers.
  4. 4You copy/paste the link. The recipient opens it; their browser reads the private key from the fragment locally.
  5. 5The recipient's browser fetches the ciphertext + sealed envelope, unwraps the file key with the fragment-private-key, verifies the hash, and decrypts.
  6. 6Optional layers (password, expiration, one-time view, watermark) are enforced server-side and within the receiver UI.

3 · Recovery flow

Account recovery without escrow
  1. 1When you create your vault, your master key is wrapped against multiple factors: your password (always), and any factor you opt in to — Recovery Key, secondary email, SMS.
  2. 2Each factor produces an independent sealed envelope. The server stores envelopes; it cannot unwrap any of them without the factor itself.
  3. 3If you lose your password, you provide a recovery factor in the browser. The browser unwraps the master key locally and prompts you to set a new password (which produces a new envelope).
  4. 4If you lose every factor, the master key is unrecoverable — by design. DRIVUNO has no backdoor.

4 · What the server can and cannot do

The server can
  • • Store and serve opaque encrypted blobs
  • • Enforce access control via Row-Level Security
  • • Log security events (logins, shares, deletions)
  • • Rate-limit and detect abusive patterns
  • • Apply expiration, one-time access, and password gates on shares
The server cannot
  • • Read the contents of your files
  • • Read file names (encrypted client-side)
  • • Derive your password or master key
  • • Decrypt shares (the key lives in the URL fragment)
  • • Reset your password into a usable state

Primitives used

  • Argon2id — password-based key derivation, tuned per-device.
  • XChaCha20-Poly1305 — authenticated encryption of file content.
  • X25519 — elliptic-curve key agreement for sealing keys to recipients.
  • Ed25519 — signing manifests for shares and protected messages.
  • HKDF-SHA-256 — subkey derivation for per-purpose keys.
  • SHA-256 — ciphertext integrity hashes (verify-before-decrypt).
  • HMAC-SHA-256 — blind-index search tags for mailbox subjects.

Full cryptographic rationale lives in the whitepaper. For what falls outside this architecture, see the threat model.

Encrypted on your device · upload in 1 click
Upload