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, including streaming chunk keys for large files
  • • X25519 share, team-folder, and Rooms channel key pairs (private halves)
  • • Recovery Key (you write it down)
Outside the boundary
What the server holds
  • • Encrypted file blobs and chunk sequences (opaque ciphertext)
  • • Sealed key envelopes (encrypted with your public key, or per-member for team folders and Rooms channels)
  • • Routing metadata: owner ID, parent ID, size, upload/chunk offsets
  • • Operational logs and lifecycle events (no content, audit-only)
  • • Account record (email, settings, hashed identifiers)
  • • API/webhook payloads (metadata and lifecycle events only, never decrypted content)

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 · Streaming encryption for large files

Chunked encryption without full-file buffering
  1. 1Large files are split into fixed-size chunks on your device rather than encrypted as one block.
  2. 2Each chunk is encrypted with a streaming AEAD construction seeded from the file key, so chunks are cryptographically bound to their position and to the stream as a whole.
  3. 3Chunks are encrypted and uploaded progressively — the browser never needs to hold the full plaintext or full ciphertext in memory at once.
  4. 4On download, chunks are fetched, verified, and decrypted in order, allowing progressive playback or extraction before the whole file has arrived.
  5. 5A final chunk marker is authenticated so a truncated or reordered stream is detected and rejected, not silently served as valid.

5 · Resumable chunked uploads

Interrupted uploads resume without re-encrypting
  1. 1Before upload, the browser records which chunks have been encrypted and confirmed as stored.
  2. 2If a connection drops (common on mobile networks with large files), the client asks the server which chunks it has and resumes from the next missing one.
  3. 3Because chunk encryption is deterministic per chunk index and file key, resuming never requires re-deriving keys or exposing plaintext a second time.
  4. 4The upload is only marked complete once every chunk is stored and the full-stream authentication check passes.

6 · Team folder keys: per-member sealing and rotation

Shared folder keys without a shared secret
  1. 1A team folder has one symmetric folder key, generated client-side when the folder is created.
  2. 2That folder key is sealed individually to every current member's public key — there is no single shared password or group secret in transit.
  3. 3Adding a member seals the existing folder key to their public key; it does not require re-encrypting folder contents.
  4. 4Removing a member triggers key rotation: a new folder key is generated, existing content is re-wrapped to the new key, and the new key is sealed only to remaining members. The removed member's envelope is deleted.
  5. 5Rotation is scoped to the folder key only — file content itself is not re-uploaded, only the small sealed envelopes are replaced.

7 · Rooms channel key distribution

End-to-end encrypted channels
  1. 1Each Rooms channel has its own symmetric channel key, generated on the creator's device.
  2. 2The channel key is sealed to each member's public key as they join, the same per-recipient sealing pattern used elsewhere in the product.
  3. 3Messages, threads, reactions, and shared items in the channel (Notes, Documents, Flowboard, Tasks, Calendar) are encrypted with the channel key or a key derived from it.
  4. 4Removing a member from a channel follows the same rotation pattern as team folders: a new channel key is issued and re-sealed to remaining members.
  5. 5P2P audio, video, and screen-share sessions negotiate their own ephemeral session key directly between participants' browsers, separate from the channel's stored-content key.

8 · Live Clone continuous replication

Ongoing encrypted sync of a local folder or disk
  1. 1You point Live Clone at a local folder or disk. Nothing is uploaded until it is encrypted on your device, same as any other upload.
  2. 2A local watcher detects changes and encrypts only the changed files or chunks, keeping replication incremental rather than re-uploading everything each time.
  3. 3Each replicated file gets an integrity hash so both sides can confirm the encrypted copy matches what was sent, without either side needing plaintext to compare.
  4. 4Read-only sharing of a replicated folder reuses the standard per-recipient sealed-envelope sharing flow — replication does not create a separate, weaker sharing path.

9 · The API and webhook boundary

Automation without a plaintext path
  1. 1API keys are scoped to specific actions and stored server-side only as hashes, never in reversible form.
  2. 2The REST API and outgoing webhooks expose metadata and lifecycle events — file created, share expired, member removed — never decrypted file or message content.
  3. 3Because the API never handles content, an API key compromise cannot expose plaintext, even though it can affect metadata, routing, or lifecycle actions until the key is revoked.
  4. 4Webhook deliveries are signed so a receiving integration can verify they originated from DRIVUNO and were not forged or replayed.

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