Technical document · v1.0 · Maintained by DRIVUNO Security

DRIVUNO Security Whitepaper

This document describes the cryptographic architecture, threat model, and operational assumptions of the DRIVUNO platform. It is intended for security engineers, auditors, and sophisticated end users. It avoids marketing language. Where DRIVUNO cannot protect a property, this document says so explicitly.

1. Architecture

DRIVUNO is a zero-knowledge cloud platform. All user content — files, filenames, message subjects, message bodies, folder names, and most metadata — is encrypted on the user's device before it ever reaches our infrastructure. The server stores ciphertext, sealed key envelopes, KDF parameters, and a minimal operational metadata projection. It does not have, and was not designed to be able to obtain, a copy of any user's master key or plaintext content.

The frontend is a TanStack Start (React 19) application served from Cloudflare Workers. Application data and authentication are backed by Supabase. Object storage uses S3-compatible backends with strict per-user RLS-style scoping. All cryptography is performed in the browser via libsodium (the audited sumo build).

2. Cryptographic primitives

We deliberately use a small set of well-reviewed primitives:

Argon2id (ALG_ARGON2ID13) for password-based key derivation.
XChaCha20-Poly1305 for authenticated symmetric encryption.
X25519 sealed boxes (crypto_box_seal) for per-recipient key wrapping.
Ed25519 for manifest signatures (public shares, protected messages).
SHA-256 for ciphertext integrity hashes and blind-index HMAC.
HMAC-SHA-256 for blind-indexed search tags on encrypted subjects.

Every file gets a fresh 32-byte random file key. The file key encrypts the file content and the encrypted filename, then is sealed once per recipient. Messages follow the same pattern with a per-message symmetric key.

3. KDF rationale

Argon2id is currently the recommended password hashing function by the IETF (RFC 9106) and the OWASP password storage cheat sheet. DRIVUNO stores per-user KDF parameters (salt, opsLimit, memLimit, algorithm tag), which lets us migrate existing accounts to stronger parameters over time without forcing a password change.

We expose three profiles: mobile (interactive),desktop (moderate), sensitive (sensitive). New accounts default to desktop on non-mobile user agents. Users on the Sensitive profile see an intentionally slower unlock (≈1 s on a modern laptop) for materially higher brute-force cost.

4. Threat model

DRIVUNO is designed so that compromise of the storage provider, database provider, or DRIVUNO's own administrative staff does not yield plaintext user content. Specifically, the platform protects against:

Server-side staff reading user files, names, or message bodies.
Database leaks (encrypted ciphertext only, no usable keys).
Storage backend compromise (encrypted blobs only, no usable keys).
Lawful access requests for plaintext content (we cannot produce what we do not have).
Mass server-side scanning, AI analysis, or content moderation of user files.

It does not protect against:

Endpoint compromise: malware, infostealers, keyloggers on the user's device.
Malicious browser extensions with access to the page.
Phishing of the user's password and recovery factors.
Screenshots and physical photography of a screen.
Active manipulation of a compromised frontend build (see §7 and §10).
Loss of all recovery factors — there is no backdoor.

5. Recovery

Each account's master key is wrapped three ways: (a) by the Argon2id-derived password key, (b) optionally by a Recovery Key (256-bit random, BIP-style chunked display), and (c) optionally by a code delivered to a verified secondary email or SMS channel. We strongly recommend enabling at least two factors.

Recovery operations are rate-limited and audited. The Recovery Key is generated client-side and is never transmitted; only its fingerprint is stored. The secondary channel codes are single-use and time-bound.

Public file shares use an ephemeral X25519 key pair. The private key lives only in the URL fragment (after the #), which browsers never send to servers. The server publishes only ciphertext, the sealed file key, and the share manifest signed with the owner's Ed25519 key. Optional password protection wraps the seed with an additional Argon2id-derived key.

Recipients verify the manifest signature against the owner's published Ed25519 public key before any decryption attempt. Tampered manifests fail verification and abort without decryption.

7. Integrity

Every encrypted file stores a SHA-256 hash of its ciphertext (content_sha256). The hash is computed and stored at upload. The downloader recomputes the hash and aborts if it disagrees, triggering an integrity alert. The hash never reveals plaintext — encryption uses fresh random nonces, so identical plaintext produces distinct ciphertexts and hashes.

8. Metadata minimization

We minimize stored metadata. Filenames, MIME types, message subjects, message bodies, and folder names are encrypted. IP addresses and user agents are retained only as needed for session security and short audit windows. Audit logs are append-only at the database level. We do not load third-party analytics, fingerprinting SDKs, or marketing pixels.

9. Session and auth

Sessions are time-bound with last-seen tracking and explicit revocation. Sensitive actions (account deletion, GDPR export, disabling 2FA, viewing recovery, managing devices) are gated by a step-up authentication challenge. Geographic anomalies on new sessions raise a warning-severity audit event.

10. Provider assumptions

We assume providers may be subpoenaed, breached, or operate inside jurisdictions hostile to privacy. The architecture does not require trust in any single provider for content confidentiality. We do trust providers for availability and durability; the multi-provider sovereignty layer documents the failover model.

Frontend integrity is the highest-leverage risk: a compromised JavaScript bundle could exfiltrate keys at unlock time. We mitigate with strict Content Security Policy (script-src self), self-hosted assets, Subresource Integrity on third-party assets where used, mandatory code review on cryptographic paths, and reproducible builds.

11. Limitations and honest caveats

We do not call DRIVUNO "unhackable", "impossible to access", or "military-grade". Such claims are misleading. What we can say accurately:

The server stores ciphertext and was not designed to be able to decrypt it.
A user who loses their password and all recovery factors loses access permanently.
A compromised endpoint can defeat any cryptography that runs on it.
No frontend code-delivery system, including ours, is immune to supply-chain attack.

Vulnerability reports: /security/disclosure — Threat model: /security/threat-model