AES-256 Encryption
Two models, one goal: your notes stay private.
Two encryption models
DocketVox uses two different encryption approaches, each designed for its specific use case:
Zero-Knowledge* Drafts & Notes
If your device supports it: when you sign in with Face ID, Touch ID, or Windows Hello on a compatible device, your encryption key is derived from a WebAuthn PRF seed that stays in your device's secure hardware. The authenticator evaluates that seed and hands the derived key to the browser, where it is used in page memory — it is never sent to or stored by DocketVox. The server cannot reconstruct the key under any circumstances; the honest caveat of any browser E2EE product is that code served by the site can read it at the moment it is used (see below).
If your device does not support PRF: DocketVox automatically generates a random 256-bit device key on first sign-in. That key lives only on your device and is never sent to the server. You are shown a one-time recovery code so you can restore your drafts on a new device — keep it safe, because it is the only way to recover your data if you lose the device.
Either way, your note content is end-to-end encrypted: it is encrypted on your device before it leaves, and the server holds only ciphertext.
* Zero-knowledge when enrolled with a device or PRF key. Enrollment happens automatically at your first sign-in; drafts created before enrollment under the retired account-derived key are migrated to your device key when you next open them. The implementation has not yet been independently verified — treat the badge as a design claim until it is.
Capability-Token Secure Send
Messages to external recipients are encrypted on your device with a random per-message key. That key is then wrapped with a 256-bit capability token that is delivered only in the link fragment (the part after #) and discarded by the server immediately. The server stores ciphertext and a wrapped key it cannot unwrap — only the recipient holding the link can decrypt, after verifying their email with a 6-digit code.
Honest boundary: the link is delivered to the recipient by email, so a Secure Send is only as strong as every mailbox or archive that ever holds that email — the recipient's inbox, your sent-mail folder, a forwarded or shared account, firm archives, or email-security gateways (Proofpoint, Mimecast, Microsoft Safe Links) that auto-open links to scan them. The capability token protects against the DocketVox server (which never sees the token and cannot decrypt), not against a party that can read any copy of the email. The 6-digit code is a mitigation, not a guarantee: it stops a scanner that merely opens the link, but a gateway that can also read the code email could complete the flow. The link — and its token — expire together with the message (3, 7, or 30 days).
Draft encryption — end-to-end, on by default
Once your account is enrolled — automatically at your first sign-in — every draft is encrypted on your device before it is stored. Drafts are end-to-end encrypted by default: there is no unencrypted fallback for new drafts. Drafts created before enrollment under the retired account-derived key are migrated to your device key when you next open them. How your encryption key is derived depends on your sign-in method:
🔒 Strongest: Face ID / Touch ID / Windows Hello — If your device and browser support WebAuthn PRF (available on modern iPhones and Macs with Touch ID; Windows Hello PRF support is newer and only present on recent Windows 11 builds, so most Windows devices use the device-key fallback below), your encryption key is derived from a PRF seed stored in your device's secure hardware chip. The authenticator evaluates the seed and returns the derived key to the browser for use in page memory — it is never sent to or stored by DocketVox, and the server cannot derive it even if fully compromised.
🔐 Standard: device key + one-time recovery code — When PRF is not available, DocketVox generates a random 256-bit device key on first sign-in and shows you a one-time recovery code. The device key is stored only in your browser and the recovery code is the only way to restore it on a new device. We ask you to confirm you have saved the code, because it is shown only once.
This is not "transport encryption" (TLS), which only protects data in transit. This is end-to-end encryption — your data is encrypted on your device with a key the server does not hold, and the server stores only ciphertext.
- AlgorithmAES-256-GCM (Galois/Counter Mode)
- Key source (PRF)Hardware authenticator (WebAuthn PRF) — seed stays in hardware; 32-byte key evaluated on-device per sign-in
- Key source (fallback)Random 256-bit device key (CSPRNG), restored via one-time base32 recovery code
- Key length256 bits
- Nonce / IV12 bytes (random, per encryption)
- Domain separationAAD bound to purpose (draft, send, signing) — ciphertext cannot be replayed across contexts
- Key persistenceHeld only in your devices — a wrapped copy your other devices can unlock is stored on the server, but the server cannot open it (the PRF-derived unwrap secret stays in your device's hardware; PRF-derived bytes live in page memory, parked briefly in session storage, scrubbed after ~60 s)
- Encryption scopeDraft text content, per save event
- Encoded formatbase64 ciphertext + base64 nonce, wrapped in JSON
Secure Send — capability-token wrapping for external recipients
When you send a note to someone without a DocketVox account, we use a capability-token model:
- A random AES-256 key encrypts your message on your device
- That key is wrapped (encrypted) with a 256-bit capability token generated on your device
- The wrapped key, ciphertext, and nonce are stored on our server. The capability token is delivered only in the link fragment and discarded by the server, so the server cannot re-derive the wrapping key
- The recipient verifies their email with a 6-digit code (2FA)
- After verification, the recipient's browser unwraps the AES key using the capability token and decrypts the message entirely client-side
- Message keyRandom AES-256-GCM (per message)
- Wrapping key256-bit capability token (CSPRNG), emailed to the recipient in the link fragment, never stored server-side
- Wrapped key storageServer-side — but the server cannot unwrap it (the capability token is never stored)
- DecryptionRecipient browser, after email 2FA verification — server cannot decrypt
- 2FA6-digit code to recipient email, 15 min expiry, 5 max attempts
- Message expiryConfigurable: 3, 7, or 30 days
- Server visibilityCiphertext + wrapped key only — no plaintext, no unwrappable key material
Speech & audio — the step E2EE can't cover
Your voice has to become text before there is a note to encrypt, so the speech-to-text step is the one place raw audio exists outside the E2EE boundary above. Two dictation modes exist; in both, raw audio never reaches DocketVox's servers:
- Browser speech (default)Unless you opt in below, dictation uses your browser's built-in Web Speech API — Google's service on Chrome/Edge, Apple's on Safari. Raw audio goes from your device to your browser vendor for transcription and is not stored by DocketVox. The resulting text is then encrypted on your device as a draft.
- On-device dictation (opt-in)Enable On-device Dictation in the app and a Whisper model runs entirely in your browser (transformers.js / ONNX Runtime; the model is fetched from a CDN on first use). Audio never leaves your device at all.
What this means: "no admin can read your transcriptions" is true of stored notes — they are end-to-end encrypted. It is not a claim about your voice before transcription, which the default mode sends to your browser vendor. If the speech-to-text step itself must never leave your device, use On-device Dictation.
Where key derivation happens
Your E2EE keys are never derived from a password or an account identifier. The WebAuthn PRF seed lives in your device's secure hardware and the authenticator evaluates it into the derived key; the device key is a raw 256-bit random value generated on your device. Neither path uses a password-based key-derivation function, because there is no password to guess.
Server-side key derivation exists only for the metadata the server must be able to read to route your messages: the routing fields above (encrypted at rest under a server key). Your notes and messages are never encrypted under a server-derivable key.
Your account PIN is an app-lock, not an encryption key. The optional 4–6 digit PIN gates re-entering the app after it locks (three failed attempts trigger a 15-minute lockout; you can reset it through your recovery email). It is not part of the E2EE key hierarchy and never wraps your drafts. The server stores only an Argon2id (m=65536, t=3, p=1 — 64 MiB, 3 iterations, parallelism 1) verifier — never the PIN in plaintext. Because a 4–6 digit code is low-entropy, that verifier is an offline-guessing target for anyone who obtains the database: Argon2id makes each guess expensive, but it cannot make a short numeric PIN strong. Treat the PIN as convenience protection against casual access to your device, not as protection against a server breach.
What this means for you
Your drafts are private by design. No server-side database stores your draft note text in readable form, and no admin panel can read your stored transcriptions. If you use Face ID / Touch ID / Windows Hello on a compatible device, the PRF seed stays in your hardware and the derived key is used in page memory. Otherwise, your key is a random device key held only in your browser and recoverable only with your one-time recovery code. Either way, the server holds only ciphertext for your note content.
One narrow exception, stated plainly. For a few moments while your encryption key is still being set up on a freshly loaded page — before encrypted storage is available — DocketVox may hold the text you have typed in this tab's transient page storage so that a reload or a sign-in round trip does not lose it. It is never sent to the server, it is discarded the instant your key is ready (and on send, clear, or tab close), and it is kept apart per signed-in account. We call this out because “encrypted at rest” should mean exactly that, and any window where it does not is worth naming rather than glossing.
Secure messages are protected by design. When sending to external recipients, the server stores a wrapped key it cannot unwrap, because the capability token that unwraps it is delivered only in the link and discarded server-side. Decryption happens entirely in the recipient's browser after email 2FA. No plaintext note content is stored on the server at any point in the flow.
Secure Send can't protect the email path itself. The decryption link is emailed, so a Secure Send is only as strong as every mailbox or archive that ever holds that email — the recipient's inbox, your sent mail, a firm's retention archive, or a security gateway (Proofpoint, Mimecast, Microsoft Safe Links) that auto-opens links to scan them. The 6-digit code stops a scanner that merely opens the link; it is not a defense against a same-tenant gateway that can also read the code email. That is the honest limit of this model.
The code that encrypts is served to you by DocketVox, as in every browser E2EE product (ProtonMail, Tutanota, and others). Encryption and decryption run in JavaScript our servers deliver to your browser. A server that is compromised — or lawfully compelled — can serve modified code that reads your key at the moment it is used, including a PRF-derived key, because the authenticator must hand the derived bytes to the page. We keep the client versioned, lean, and audited; a browser cannot fully defend against its own origin.
Save your recovery code. Your recovery code is the only way to restore your drafts on a new device. It is shown once at enrollment and is not stored by DocketVox — if you lose both your device and the code, your encrypted drafts cannot be recovered. That is the trade-off of end-to-end encryption: we cannot recover what we cannot read.