SeraVault is a zero-knowledge, end-to-end encrypted file storage and messaging platform designed to resist
attacks from both classical and quantum computers. The system employs ML-KEM-768 (NIST FIPS 203), a
lattice-based key encapsulation mechanism standardized by NIST for post-quantum cryptography, combined with
AES-256-GCM for symmetric encryption.
This whitepaper provides a comprehensive technical description of SeraVault's cryptographic architecture,
security model, and implementation. We detail our zero-knowledge design, key management protocols, and
post-quantum cryptographic primitives.
Note: This is a living document. As cryptographic standards evolve and security research
progresses, we will update our implementation and this documentation accordingly. The current version reflects
the production system as of November 2025.
2. Threat Model
2.1 Adversary Capabilities
SeraVault is designed to protect against the following adversaries:
2.1.1 Server Compromise
We assume the server infrastructure can be fully compromised. An attacker gaining complete access
to our servers should not be able to decrypt user files or messages. This is achieved through client-side
encryption where encryption keys never reach the server in plaintext form.
2.1.2 Network Adversary
We assume an adversary can intercept, modify, or inject network traffic between clients and servers. TLS
provides transport-level security, but our application-layer encryption ensures that even TLS compromise
does not expose plaintext data.
2.1.3 Quantum Adversary
We anticipate future adversaries with access to cryptographically-relevant quantum computers (CRQC). Traditional
public-key cryptosystems like RSA and elliptic curve cryptography are vulnerable to Shor's algorithm. SeraVault
uses ML-KEM-768, which is based on the hardness of lattice problems believed to be resistant to quantum attacks.
2.1.4 State-Level Adversary
We design against state-level actors with significant computational resources, the ability to compel service
providers, and "Harvest Now, Decrypt Later" capabilities where encrypted data is stored for future decryption
when quantum computers become available.
2.2 Trust Assumptions
Client Device Security: We assume the user's device is not compromised. Client-side malware can always defeat encryption.
Cryptographic Primitives: We trust NIST-standardized cryptographic algorithms (ML-KEM-768, AES-256-GCM).
Cryptographic Implementation: ML-KEM-768 is provided by the open-source @noble/post-quantum library, validated against the NIST FIPS 203 known-answer test vectors. As of this writing the library has not undergone an independent third-party security audit; it is auditable pure-JavaScript with no external runtime dependencies beyond @noble/hashes. AES-256-GCM and ChaCha20-Poly1305 use the browser's native Web Crypto API and the audited @noble/ciphers library.
Random Number Generation: We rely on the browser's crypto.getRandomValues() for cryptographically secure random numbers.
User Passphrase Strength: For passphrase-based authentication, we assume users choose sufficiently strong passphrases (minimum 12 characters).
2.3 Out of Scope
The following threats are explicitly out of scope:
Side-channel attacks on client hardware
Physical access to unlocked client devices
Coercion or social engineering of users
Metadata analysis (file access patterns, upload times, file sizes are visible to servers)
2.4 Browser Extensions
Browser extensions deserve their own entry rather than a line in the out-of-scope
list, because they are the most realistic client-side threat most users face.
An extension granted access to this application's origin (or to all sites, a
permission users grant routinely) can inject scripts into the page itself. From
there it can capture your passphrase as you type it, read decrypted content as
it is displayed, and intercept data before encryption or after decryption.
No web application can defend against this. Content Security
Policy does not bind extensions, and no code a page ships can detect or resist
a script injected at the same privilege level. This is a property of the browser
platform shared by every browser-delivered encryption product, not a SeraVault
limitation — and any product claiming otherwise should be treated with
suspicion. Hardware-backed credentials limit the damage in one narrow way: an
extension cannot extract secrets from a security key or passkey authenticator.
It can, however, read whatever those secrets decrypt once the page displays it.
Mitigation: a dedicated, extension-free browser profile.
Browser extensions are installed per profile. Creating a separate browser
profile with no extensions — and using it exclusively for SeraVault — removes
the entire class of threat while keeping every unlock method available:
security keys, synced passkeys, and phone-via-QR all work normally, because
the profile is still a full browser. Installing SeraVault as an app from that
profile gives it its own window and icon. This matters most at account
creation, when your keys are generated. Auditing the extensions in an everyday
profile is weaker but better than nothing; treat any extension with
access to all sites as able to read anything you decrypt.
Managed deployments can enforce this at the browser level.
Chromium-based browsers under enterprise management support the
ExtensionSettings policy with
runtime_blocked_hosts: an administrator can declare that no
extension may run on or inject into app.seravault.com,
enforced by the browser itself regardless of what users have installed —
extensions keep working on every other site. The policy is deployed
through Group Policy, Intune, or the Google Admin console (for example,
"runtime_blocked_hosts": ["*://app.seravault.com"] applied
to the wildcard extension ID *), and Firefox and Edge offer
equivalent policy controls. For organizations, this converts the
extension threat from a user-education problem into an enforced
configuration.
Device-level malware (keyloggers, screen capture, OS compromise) remains out of
scope for both environments: no application can protect data on a machine the
attacker already controls.
3. System Architecture
3.1 Zero-Knowledge Design
SeraVault implements a true zero-knowledge architecture where the server has no access to:
Plaintext file contents
Encryption keys (except in encrypted form)
File names, folder structures, or other metadata
Message contents in the encrypted chat system
All encryption and decryption operations occur client-side in the user's browser or application. The server
stores only encrypted data and acts as a dumb storage and synchronization layer.
3.2 Component Overview
3.2.1 Client Application
React-based web application running entirely in the browser
Implements all cryptographic operations using Web Crypto API and WebAssembly
Manages user keys and authentication
Handles file encryption/decryption, metadata encryption, and secure sharing
3.2.2 Cloud Backend
Backend Database: Stores encrypted file metadata, user profiles, sharing permissions
Object Storage: Stores encrypted file blobs
Authentication Service: Handles user authentication (email/password, not used for encryption keys)
Cloud Functions: Minimal server-side logic for notifications and cleanup (no access to plaintext data)
3.3 Data Flow
File Upload Flow
User selects file in browser
Client generates random 256-bit symmetric key (File Key)
Client encrypts file content with AES-256-GCM using File Key
Performance: Fast key generation and encapsulation/decapsulation
Quantum Resistance: Based on Learning With Errors (LWE) over module lattices, believed secure against quantum attacks
4.2 AES-256-GCM
Advanced Encryption Standard with 256-bit keys in Galois/Counter Mode provides authenticated
encryption for file contents.
Properties
Key Size: 256 bits
Nonce Size: 96 bits (12 bytes), randomly generated per encryption
Authentication Tag: 128 bits (16 bytes)
Security: Provides both confidentiality and authenticity
Quantum Resistance: Grover's algorithm reduces effective key size to 128 bits, still secure
4.3 ChaCha20-Poly1305
ChaCha20-Poly1305 is a high-speed authenticated encryption algorithm used to protect sensitive
key material (like your private key) at rest.
Usage: Encryption of user private keys using passphrase-derived keys
Performance: Extremely fast in software, ideal for mobile devices
Security: Immune to timing attacks (constant time), provides 256-bit security
Adoption: Standardized in RFC 8439, used by Google, Cloudflare, and WireGuard
4.4 Argon2id
Argon2id for deriving encryption keys from user passphrases. Winner of the Password Hashing Competition (2015).
Time cost: 3 iterations
Memory cost: 64 MiB (65536 KiB)
Parallelism: 4 threads
Salt: 128-bit random value, unique per encryption
Output: 256-bit key
Why Argon2id: Argon2id is memory-hard, making GPU and ASIC attacks expensive. It combines
data-independent (Argon2i) and data-dependent (Argon2d) approaches for side-channel resistance and
maximum protection against parallel cracking attempts.
5. File Encryption Protocol
5.1 Key Generation
When a user first creates their account and generates their encryption keys:
// Generate ML-KEM-768 keypair
(publicKey, privateKey) = ML-KEM-768.KeyGen()
// Derive encryption key from passphrase
salt = CSPRNG(32 bytes)
encryptionKey = Argon2id(passphrase, salt, t=3, m=64MiB, p=4, 32 bytes)
// Encrypt private key with passphrase-derived key
nonce = CSPRNG(12 bytes)
encryptedPrivateKey = ChaCha20-Poly1305.Encrypt(encryptionKey, nonce, privateKey)
// Store encrypted private key in backend database
// Public key stored in backend database (plaintext, it's public)
5.2 File Encryption
For each file uploaded:
// 1. Generate random file encryption key
fileKey = CSPRNG(32 bytes)
// 2. Encrypt file content
nonce = CSPRNG(12 bytes)
encryptedContent = AES-256-GCM.Encrypt(fileKey, nonce, fileContent)
// Result includes 16-byte authentication tag
// 3. Encapsulate file key for owner
(ciphertext, sharedSecret) = ML-KEM-768.Encapsulate(ownerPublicKey)
// Shared secret is used to encrypt the file key
keyNonce = CSPRNG(12 bytes)
encryptedFileKey = AES-256-GCM.Encrypt(sharedSecret, keyNonce, fileKey)
// 4. Encrypt metadata
metadata = {name, size, type, uploadDate}
metadataNonce = CSPRNG(12 bytes)
encryptedMetadata = AES-256-GCM.Encrypt(userSharedSecret, metadataNonce, metadata)
Unlike many encrypted storage systems, SeraVault encrypts file metadata including:
File names
File sizes
MIME types
Folder paths
Upload timestamps
This prevents the server from building a profile of user activity patterns based on file names or types.
Metadata Visibility: While content and names are encrypted, the server still knows:
Encrypted blob sizes (approximate file sizes)
Upload/modification timestamps
Number of files per user
Sharing relationships (user A shared something with user B)
This is inherent to any cloud storage system and cannot be fully eliminated without using techniques like
ORAM (Oblivious RAM), which would severely impact performance.
6. Key Management
6.1 User Key Hierarchy
Each user has multiple keys serving different purposes:
Key Type
Purpose
Storage
ML-KEM-768 Public Key
File key encapsulation (others encrypt for you)
Backend database (plaintext)
ML-KEM-768 Private Key
File key decapsulation
Backend database (encrypted once with AES-256-GCM under the DEK)
Data Encryption Key (DEK)
Encrypts the private key
Never stored in the clear; one wrapped copy per unlock method in the backend database
Shared Secret
Metadata encryption
Derived from ML-KEM-768 key pair
Passphrase-Derived Key
Encrypts the DEK
Derived on-demand, never stored
WebAuthn PRF Output
Encrypts the DEK
Released by the authenticator after user verification; never stored
6.2 Key Storage Locations
Important: SeraVault supports multiple authentication methods simultaneously. Users can enable
passphrase authentication, hardware key authentication, and biometric authentication at the same time.
These methods are layered using envelope encryption. The ML-KEM-768 private key is encrypted
exactly once, with AES-256-GCM, under a randomly generated 256-bit Data Encryption Key (DEK). Each enabled
authentication method then encrypts only the DEK — a 32-byte secret — rather than its own full copy of the
private key:
DEK = random 256 bits
private key --AES-256-GCM under DEK--------------> encryptedPrivateKeyV4 (one copy)
DEK --ChaCha20-Poly1305 under Argon2id(passphrase)--> wrappedDeks.passphrase
DEK --AES-256-GCM under WebAuthn PRF(credential A)--> wrappedDeks[credential A]
DEK --AES-256-GCM under WebAuthn PRF(credential B)--> wrappedDeks[credential B]
This yields two properties that per-method key copies cannot provide. First, adding an authentication method
costs 32 bytes of wrapped key material instead of another full copy of the private key. Second, revocation can
be made cryptographically meaningful: when a credential is removed, the DEK is rotated — a new DEK is generated,
the private key is re-sealed under it, and fresh wraps are issued for the remaining methods. Every
previously-issued wrap then opens nothing, including copies retained outside the live database.
Rotation requires the surviving methods to be re-wrappable. A PRF wrap can only be rebuilt while
its authenticator is physically present to produce the PRF output. Rotation therefore runs when the user confirms
removal with their passphrase and the surviving set can be reconstructed. If other hardware credentials remain
that cannot be re-wrapped at that moment, SeraVault deletes the revoked wrap but does not rotate —
re-sealing would lock those authenticators out of the vault. In that case the revoked credential is removed from
the live record but a retained copy of its wrap would still open the old ciphertext, so users are told the vault
was not fully re-secured.
Envelope encryption protects the private key only. File content is encrypted with per-file AES-256-GCM keys that
are encapsulated to the ML-KEM-768 public key; the private key merely decapsulates them. Files, folders,
and existing shares are never re-encrypted when unlock methods change.
6.2.1 Passphrase Authentication
The primary authentication method where the private key is encrypted with a passphrase-derived key and stored in the backend database:
User creates strong passphrase (minimum 12 characters)
Passphrase derives encryption key via Argon2id (64 MiB memory-hard)
Private key encrypted with derived key using ChaCha20-Poly1305
Encrypted private key stored in backend database
On login: Encrypted private key downloaded and decrypted with passphrase
Decrypted private key held in browser memory during session
Private key discarded on logout
6.2.2 Hardware Key Authentication
Users can enable hardware key authentication in addition to or instead of passphrase authentication. Private keys are
protected by a hardware security key (YubiKey, Titan Key) using FIDO2/WebAuthn:
Requires an authenticator supporting the WebAuthn PRF extension (CTAP2 hmac-secret)
The authenticator releases a high-entropy PRF secret only after successful user verification
That PRF output encrypts the DEK with AES-256-GCM; the wrapped DEK is stored in the backend database
The PRF output is not derivable from the credential ID or any other public value
The hardware key must be physically present and verified to release it
DEK and private key are decrypted only when needed and held transiently in memory
Works with PRF-capable FIDO2 authenticators (YubiKey 5 firmware 5.2.3+, Titan Key, etc.)
Because the wrapped DEK is stored server-side rather than in browser storage, hardware key unlock works on any
device the authenticator is presented to, and clearing browser data does not destroy access.
Hardware Key Trade-off: If using hardware keys without passphrase authentication, losing the
hardware key means losing access to your encrypted data unless you have a backup key or exported key file. The
wrapped DEK cannot be decrypted without the physical hardware key present to release its PRF output.
Superseded design: Earlier versions wrapped the private key with a key derived via Argon2id
from the credential ID and user ID, storing the result in browser IndexedDB. Because both inputs are public
values, such a blob was decryptable offline without the authenticator ever being present. That format is no
longer created. Any remaining blob is migrated to the PRF-protected scheme above on first use and then deleted
from IndexedDB.
6.2.3 Biometric Authentication
Users can enable biometric authentication (fingerprint, Face ID) for convenient access on mobile devices:
Uses the same WebAuthn PRF mechanism as hardware key authentication
Biometric verification (fingerprint, Face ID, or device PIN) releases the PRF secret
That PRF output encrypts the DEK with AES-256-GCM; the wrapped DEK is stored in the backend database
Only the wrapped DEK leaves the device — the PRF secret never does, and the private key never does
Each registered credential gets its own independent wrap, so several devices can coexist
Works with the device's native biometric sensors on PRF-capable browsers
Because the wrapped DEK is stored server-side, biometric unlock survives browser storage being cleared, and a
passkey that syncs between a user's devices can unlock the vault on each of them.
6.2.4 Key File Backup
Users can export their private key encrypted with a separate passphrase:
User generates strong backup passphrase
Private key re-encrypted with backup passphrase-derived key
Encrypted key file downloaded by user
User stores key file securely offline
Can be used to recover access if primary authentication method is lost
6.3 Key Rotation
SeraVault supports key rotation to maintain forward secrecy:
Key Rotation Process
User generates new ML-KEM-768 keypair
For each file owned by user:
Decrypt file key using old private key
Re-encapsulate file key using new public key
Update backend database with new encapsulated key
For each shared file:
Notify sharing partners of key change
Re-encapsulate shared keys with new public key
Old private key securely erased
New public key published
Performance Consideration: Key rotation for users with thousands of files can be time-consuming.
The operation is performed incrementally in the background.
7. Secure File Sharing
7.1 Sharing Model
SeraVault implements per-recipient key encapsulation for file sharing:
Per-Recipient Keys: Each recipient gets their own encapsulated copy of the file key
No Re-encryption: File content is not re-encrypted, only the file key is re-encapsulated
Instant Revocation: Owner can revoke access by deleting recipient's encapsulated key
Forward Secrecy: Revoking access prevents future access, but recipient may have cached plaintext
Post-Quantum: Sharing uses ML-KEM-768, resistant to quantum attacks
7.3 Permission Model
Permission
Description
Owner
Full control: read, modify, delete, share, revoke
View
Can decrypt and view file, cannot modify or share
Currently, SeraVault implements a simple owner/view permission model. Shared users can view files but cannot
modify them or share with others.
7.4 Group Sharing
For sharing with multiple users, the owner can create a "group share":
Owner selects multiple recipients
System encapsulates file key for each recipient individually
All recipients get simultaneous access
Owner can revoke individual users without affecting others
Storage Cost: Each shared file requires storing one encapsulated key per recipient (~1 KB).
For large-scale sharing, this is negligible compared to the file content itself. Only the file owner's storage
quota is consumed, regardless of how many people it's shared with.
8. Authentication Methods
8.1 Multi-Factor Authentication
SeraVault separates account authentication from encryption key access:
Account Authentication: Proves you are the account owner (authentication service)
Key Access: Proves you can access the encryption keys (passphrase, biometric, hardware key)
8.2 Passphrase-Based Authentication
The default authentication method:
User creates strong passphrase (minimum 12 characters enforced)
Passphrase used to derive key via Argon2id (64 MiB memory cost)
Derived key encrypts the user's ML-KEM-768 private key
Passphrase never sent to server
Encrypted private key stored in backend database
8.3 Biometric Authentication
Uses WebAuthn with platform authenticators:
Leverages device biometric sensors (fingerprint, Face ID)
Private key encrypted with credential derived from WebAuthn
Private key stored in browser's IndexedDB, encrypted
Biometric data never leaves device
Requires WebAuthn support in browser
8.4 Hardware Key Authentication (YubiKey)
Uses FIDO2/CTAP2 for hardware-backed authentication:
Standard Mode: YubiKey used for WebAuthn authentication, keys encrypted and stored as usual
Paranoid Mode: Private keys stored exclusively on YubiKey, never on servers
Supports YubiKey 5 series with HMAC-secret extension
Requires physical key presence for all operations in Paranoid Mode
8.5 Passkey (Platform Authenticator)
Modern passwordless authentication using WebAuthn:
Stored in device's secure enclave (TPM, Secure Enclave)
Synced across user's devices via platform (iCloud Keychain, Google Password Manager)
Combines security and convenience
Phishing-resistant authentication
9. Encrypted Messaging
9.1 Chat Architecture
SeraVault includes end-to-end encrypted messaging using the same cryptographic primitives as file encryption:
9.2 Conversation Key Exchange
// Creating a conversation
// 1. Initiator generates random conversation key
conversationKey = CSPRNG(32 bytes)
// 2. For each participant (including initiator):
(ciphertext_i, sharedSecret_i) = ML-KEM-768.Encapsulate(participant_i_PublicKey)
nonce_i = CSPRNG(12 bytes)
encryptedConversationKey_i = AES-256-GCM.Encrypt(sharedSecret_i, nonce_i, conversationKey)
// 3. Store encrypted conversation keys in backend database
// Each participant can decrypt using their private key
Mitigation: Without user passphrases or hardware keys, attacker cannot decrypt. Zero-knowledge architecture limits damage to encrypted data collection.
11.1.2 Passive Network Eavesdropping
Threat: Attacker intercepts network traffic.
Impact: Low. TLS protects transport, but even TLS compromise exposes only encrypted data.
Mitigation: Application-layer encryption ensures plaintext never transmitted. Metadata encrypted.
11.1.3 Quantum Computer Attack
Threat: Future quantum computer attempts to break encryption.
Impact: Low for ML-KEM-768 protected data. Symmetric encryption (AES-256) security reduced but still strong.
Mitigation: ML-KEM-768 based on lattice problems resistant to known quantum algorithms. AES-256 provides 128-bit security against quantum attacks (Grover's algorithm), sufficient for most use cases.
11.1.4 Weak Passphrase
Threat: User chooses weak passphrase, attacker performs offline brute-force.
Impact: High if successful. Attacker decrypts private key and gains access to all files.
Mitigation:
Minimum 12-character passphrase requirement
Argon2id memory-hard hashing (64 MiB) makes GPU/ASIC attacks expensive
Encourage hardware key usage for high-value accounts
User education on passphrase strength
11.1.5 Phishing
Threat: User tricked into entering passphrase on malicious site.
Impact: High. Attacker obtains passphrase and can decrypt private key.