VANISHKEY SECURITY MODEL — PROTOCOL v3
=======================================

Sender-generated CSPRNG material:
- 256-bit lookup identifier
- random 8-bit fragment framing byte (no fixed fragment prefix)
- independent 256-bit master secret
- independent 256-bit reveal capability
- fresh 96-bit AES-GCM IV

Encryption and key schedule:
- AES-256-GCM with a 128-bit authentication tag
- HKDF-SHA-256 derives the AES key from the master secret and binds it to the id
- optional passphrases use PBKDF2-HMAC-SHA-256 with 600,000 iterations
- AAD is UTF-8 "vanishkey:v3:<identifier>:<kdf-mode>"
- a SHA-256 key commitment detects incorrect derived material
- plaintext encryption and decryption happen on endpoint devices

URL fragment:
- v3 without a passphrase: random frame || master secret || reveal capability
- v3 with a passphrase: the above plus random salt || key commitment
- every byte before base64url encoding is random or cryptographically derived;
  there is no fixed version byte, punctuation marker, or deterministic prefix
- legacy 64-byte v2 fragments remain decryptable during transition

Server and in-memory store:
- create receives ciphertext, IV, non-secret KDF metadata, key commitment, and
  SHA-256(reveal capability)
- the active key incorporates the reveal verifier
- creation applies create-only semantics and a 3,600-second TTL atomically
- reveal requires the raw reveal capability but never the AES key
- a correct capability performs an atomic validated get-and-delete
- a wrong or missing capability cannot retrieve or delete a secret

Web behavior and controls:
- opening a complete non-passphrase link automatically reveals once
- passphrase links wait only for the separate passphrase, which is checked
  locally before the one-time payload is consumed
- per-request nonce-based strict CSP without unsafe-inline
- no-store secret/API responses and noindex reveal pages
- 1,000 UTF-8 byte plaintext ceiling, enforced by endpoint clients and the API
- trusted browser-origin checks, JSON type/size limits, and abuse throttles
- no accounts, cookies, advertising trackers, or behavioral analytics
- successful creations, reveals, and Mailgun-accepted deliveries increment
  only UTC date-bucketed aggregate counters; no secret or client identifier is
  written with the counters

Direct email:
- complete link passes through VanishKey and Mailgun when explicitly chosen
- every valid direct-email submission records only its normalized recipient
  address plus first-seen, last-seen, and submission-count metadata
- a ledger failure stops delivery; the complete URL and fragment are never
  written to the recipient record

Limitations:
- anyone with the complete URL (and passphrase, if set) can reveal the secret
- compromised endpoints, extensions, clipboards, or delivery channels can
  expose the complete URL or plaintext
- passphrase key commitments permit offline guessing by a link holder;
  PBKDF2 increases guessing cost but cannot rescue a weak passphrase
- recipients can copy plaintext after reveal
- infrastructure may retain encrypted remnants; the AES key is not stored
  with those bytes
- traffic analysis and denial of service cannot be eliminated
- VanishKey has not received a third-party cryptographic or penetration audit

Reporting:
https://vanishkey.com/.well-known/security.txt