TECHNICAL DOCUMENT · v1.0 · 2026
VaultPass Security Whitepaper
A technical description of the encryption flow, key management architecture, and Dead Man’s Switch protocol that underlies the VaultPass inheritance system.
Threat Model
VaultPass is designed to protect against three primary adversaries: (1) a compromised VaultPass server, (2) a network-level attacker intercepting traffic, and (3) an heir attempting to access the vault before the trigger condition is met.
The core property we guarantee: no single party — including VaultPass — can decrypt a vault without (a) the user's AES key and (b) the heir's Shamir shard. Both are required. Neither is ever stored in the same place.
Vault Encryption (Client-Side)
All encryption happens inside the user's browser via the Web Crypto API. No plaintext ever leaves the device.
Step 1 — Key generation: crypto.subtle.generateKey({ name: 'AES-GCM', length: 256 }, true, ['encrypt','decrypt']) produces a cryptographically random 256-bit key.
Step 2 — IV generation: crypto.getRandomValues(new Uint8Array(12)) produces a 96-bit initialisation vector. AES-GCM with a 96-bit IV is the NIST-recommended configuration (SP 800-38D).
Step 3 — Encryption: crypto.subtle.encrypt({ name: 'AES-GCM', iv }, key, plaintext) produces an authenticated ciphertext with a 128-bit GCM authentication tag appended. Tampering with the ciphertext causes decryption to fail with an authentication error.
Step 4 — Serialisation: The vault blob is stored as base64(IV) + '.' + base64(ciphertext). The raw AES key is exported and delivered to the heir separately.
Key Sharding (Shamir's Secret Sharing)
The raw AES key is split into N shards using Shamir's Secret Sharing (SSS). Any M-of-N shards can reconstruct the key; possession of fewer than M shards reveals zero information about the key.
Default configuration: 2-of-3 split. The user retains the owner shard. VaultPass holds the heir shard and the sentinel shard, both encrypted at rest, and combines them only after the Dead Man's Switch triggers. Any two shards reconstruct the key; any one alone reveals nothing about it.
Because we hold two of the three shards, VaultPass is capable of reconstructing a vault key in the succession path. That is why we describe the product as client-side encrypted rather than zero-knowledge. Removing this capability — so that no reconstructing set is ever held by us — is the next architecture milestone.
Mathematical basis: SSS uses polynomial interpolation over a finite field (GF(2^8)). A degree-(M-1) polynomial is constructed such that f(0) = secret, and each shard is a point on the curve. Any M points uniquely determine the polynomial; fewer than M yield no information.
Dead Man's Switch Protocol
The switch has three states: MONITORING, WARNED, and TRIGGERED.
MONITORING: The user performs periodic check-ins. Each check-in updates last_check_in in the database (a Supabase Postgres row). The check-in endpoint validates the user's JWT before accepting the update.
WARNED: When elapsed time > 75% of the configured interval, Inngest dispatches warning emails to both the user and heir. This is the 'redemption window.'
TRIGGERED: At 100% elapsed time, Inngest marks the switch as triggered. A 7-day safety buffer begins — a second chance for false positives (hospitalisation, travel). If not cancelled within 7 days, the system authorises heir key delivery.
CANCELLED: Any check-in during the triggered or warned state resets the switch and cancels all pending heir notifications.
Data Architecture
VaultPass stores: (1) the encrypted vault blob — ciphertext only, (2) the heir's email address in plaintext, (3) the last_check_in timestamp, (4) the check_in_interval_days setting.
VaultPass never stores: (1) the plaintext vault secret, (2) the AES decryption key, (3) any Shamir shard belonging to the user or heir.
Database: Supabase Postgres with Row Level Security (RLS) policies. A user can only read and write their own profile row. The service-role key (used by background jobs) never runs on the client.
Transport: All API calls use HTTPS/TLS 1.3. HSTS is enforced. The Supabase anon key is scoped to authenticated operations only.
Verification
Every claim in this document is verifiable without trusting VaultPass. The Interactive Demo (/demo) lets you run the encryption in your browser and inspect the output. Open DevTools → Network to confirm no requests are made during encryption.
The core cryptographic primitives (AES-256-GCM, SHA-256, the CSPRNG) are implemented by your browser vendor, not by VaultPass. We call the Web Crypto API; the only cryptography we implement ourselves is the Shamir's Secret Sharing math, which is open-source in crypto-core.
The crypto-core module (AES-256-GCM, SHA-256, Shamir's Secret Sharing) is already open-source and MIT-licensed on GitHub. An independent third-party professional audit is planned; the report will be published in full at /security.