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).
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
Malicious browser extensions or compromised browsers
Metadata analysis (file access patterns, upload times, file sizes are visible to servers)
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 with passphrase-derived key)
Shared Secret
Metadata encryption
Derived from ML-KEM-768 key pair
Passphrase-Derived Key
Encrypts private key
Derived on-demand, 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. Each method
stores an independently-encrypted copy of the private key in different locations, providing redundancy and flexibility.
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:
Private key encrypted with key derived from hardware key's credential ID (via Argon2id)
Encrypted private key stored in browser's IndexedDB (client-side only)
Private key never sent to any server
Hardware key must be physically present to derive decryption key
Private key decrypted only when needed, held transiently in memory
Works with any FIDO2 authenticator (YubiKey 5, Titan Key, etc.)
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 encrypted private key in IndexedDB cannot be decrypted without the physical hardware key present.
6.2.3 Biometric Authentication
Users can enable biometric authentication (fingerprint, Face ID) for convenient access on mobile devices:
Private key encrypted with key derived from WebAuthn credential ID (via Argon2id)
Encrypted private key stored in browser's localStorage (client-side only)
Private key never sent to any server
Biometric authentication required to derive decryption key
Works with device's native biometric sensors
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.