Security design
Your vault is encrypted and split entirely in your browser.
Vault plaintext, the recovery key, and Shamir share contents are not sent to DMSKey. The backend processes payment and licence metadata — not seeds.
- Client-side AES-256-GCM
- Threshold key splitting
- No vault upload
Security review status
No independent audit yetThe cryptographic design has not yet undergone an independent third-party security audit. The design, threat model, and source references are published so they can be reviewed: AES-256-GCM authenticated encryption, Shamir secret sharing over GF(2⁸), and the documented vault format are reproducible from the published source. The properties below depend on running an authentic, uncompromised build in a trusted browser. Vault format: dms.v1.
Threat model, at a glance
What the design protects against, and what it explicitly does not.
Protects against
- Loss of fewer than N − K + 1 shares
- One curious custodian acting alone
- Server-side exposure of vault plaintext
- Accidental mixing of artifacts from different vaults
Does not protect against
- A compromised device or operating system
- A malicious browser extension
- A fake or tampered recovery page
- Cooperation between K custodians
- Missing estate instructions or wallet metadata
The privacy boundary, at a glance
DMSKey is designed so the secret material never reaches the hosted backend. The right column lists what the server processes; the left column lists what stays local to your browser.
Stays on your device
- Vault contents (seed phrase, instructions, written secrets)
- 256-bit AES recovery key
- Contents of each Shamir share
- Decrypted vault during recovery
- Generated share-card data and PDF output
DMSKey backend never sees
- Your seed phrase
- The recovery key
- The contents of any Shamir share
- The decrypted vault
- A DMSKey username or password
What the browser actually does when you click Create
Design choices
Authenticated encryption
AES-256-GCM gives authenticated encryption: a tampered ciphertext or a wrong key produces an authentication failure rather than silent garbage plaintext.
Threshold splitting, not naive splitting
Shamir over GF(2⁸) gives true threshold splitting; a valid set of fewer than K shares does not reveal the secret itself.
Dedicated Worker for isolation
Cryptographic operations run in a dedicated Worker, keeping key handling away from the DOM. This is not a defence against a compromised browser, extension, or application bundle — for high-value vaults use a trusted device.
No vault-data endpoints on the backend
The intended application flow does not transmit vault plaintext, recovery keys, or share contents to the DMSKey backend.
The cryptography is identical at every tier
Free and DMS Full use the same AES-256-GCM encryption, the same threshold key splitting, the same Web Worker isolation. Paying changes what you can produce, not what you can open. See full pricing on the inheritance plan.
Questions about the security design
Can DMSKey decrypt my vault?
The intended application flow does not transmit vault plaintext, the recovery key, or share contents to the DMSKey backend. The encryption key never leaves your browser as a single value — only as K-of-N Shamir shares.
Is browser-based encryption safe for a Bitcoin seed phrase?
Browser cryptography moves the trust boundary to your device and to the application bundle you load. The strong properties are real (no upload, no escrow, no key custody), but they depend on the integrity of the device, browser, and bundle. For high-value vaults, use a trusted device, verify the application source, and keep the offline recovery package with the cards.
Has DMSKey been independently audited?
DMSKey has not yet undergone an independent professional security audit. The cryptographic design, threat model, and source references are published so they can be reviewed.
What does DMSKey not protect against?
A compromised browser or operating system, a malicious browser extension with sufficient privileges, a tampered application bundle, K custodians colluding, physical destruction of more than N-K cards, mistakes when entering the original secret, and missing wallet metadata such as a BIP-39 passphrase or derivation path.
Does the ciphertext reveal anything about the vault?
AES-GCM ciphertext is the same length as the plaintext plus a 16-byte authentication tag, so the encrypted package size reveals the byte length of the encoded vault. It does not reveal the contents, the word count of a seed phrase, or wallet metadata, but the size is observable.
Read the design, then run it
The Create page runs the code path described above. Watch the network panel as you click through — the intended flow does not upload vault plaintext, the recovery key, or share contents.