Everything you need to know about Legacy Encryption
It depends on whether you're still around to fix it.
If you're alive, nothing is lost. Your seed phrase — backed up physically, as it always should be — is the source of truth. Just choose new keys and re-encrypt. This is why Legacy is a protocol you maintain, not a one-time action: periodically confirm your keys still decrypt, and re-encrypt whenever a key is lost, forgotten, or possibly compromised.
If it's for inheritance and you're gone, a lost key means that encrypted copy can't be opened — and unless there's another means of retrieval, those coins are unreachable. Legacy stores no data and cannot recover keys for you. That's exactly why we recommend redundancy: multiple copies of the encrypted QR and a sealed break-glass fallback (see Who It's For).
The key principle: always maintain a physical backup of your seed phrase. Legacy does not replace your primary seed backup — it is a means of recovery and transfer, layered on top of it.
Yes. You can create as many Benefactor/Beneficiary key combinations as you like, each associated with a different seed phrase.
Download Legacy-offline.html from GitHub.
Recommended — fully air-gapped on SeedSigner: Load the file onto your SeedSigner. Your seed phrase never touches an internet-connected device at any point in the process.
Alternative: Disconnect from wifi and open the file in any web browser on your computer.
No. Beneficiary Key and Benefactor Key may contain all uppercase, lowercase, numbers, and special characters.
The Beneficiary needs to receive:
See Deadman Switch options for setup guidance.
The best keys are 4–5 random, unrelated words separated by spaces — for example, cloud mango river tuesday. This gives you high entropy while remaining memorable enough to carry in your head or communicate verbally to your Beneficiary. Never write both keys down together or store them with the encrypted QR.
Legacy uses PBKDF2 with 600,000 iterations of SHA-256, making even a modest passphrase extremely resistant to brute force. The two keys are the two halves of one combined password (joined by an untypeable separator), so an attacker who obtains only one half still has to brute-force the other — they need both to decrypt. Note this is a single split password, not threshold cryptography.
Keep the Benefactor Key and Beneficiary Key stored separately. Never store either key alongside the encrypted QR.
✓ Good keys — random, unrelated words with no personal connection:
cloud mango river tuesdaylamp orbit forest eleven quietthunder anchor velvet paradeseven bridge harbor silk moonarctic bench window plum escape✗ Bad keys — guessable by anyone who knows you:
bitcoin — single obvious wordsatoshi2009 — predictable Bitcoin referencejohn1985 — name + birth year, trivially guessablepassword123 — among the most common passwords in existenceiloveyou — common and emotionally predictable for an inheritance toolNote: the examples above are illustrations only — do not use them. Choose your own words at random.
SeedSigner is the recommended way to use Legacy — the entire workflow runs air-gapped. Encrypt on SeedSigner, scan the QR into your Deploy email, and your seed phrase never touches the internet.
For best results when scanning an encrypted QR into SeedSigner:
Visit the Protocol page for a detailed summary.
Take your time — there is no time pressure, and nothing in the email is secret on its own. The encrypted payload is useless without the two passwords.
Normal path: open the Legacy Decryption page (or your saved copy of Legacy-offline.html) on an offline computer, paste the ciphertext into the Encrypted Seed Phrase field, enter your Beneficiary Key and the Benefactor Key, and click Decrypt.
Do NOT type the passwords into any other website, and do not share them with anyone who offers to "help recover" — run everything offline.
If no copy of the tool runs anymore: any software engineer can rebuild decryption from the specification below using any mainstream cryptography library.
TECHNICAL SPECIFICATION OF THE ENCRYPTED PAYLOAD (Legacy protocol)
Version detection:
- If the payload string starts with "LE2." it is version 2.
- Otherwise it is version 1.
Common to both versions:
- Key derivation: PBKDF2-HMAC-SHA256, 600,000 iterations (v2 stores the
exact count in its header), 16-byte random salt, output 32 bytes.
- Cipher: AES-256-GCM, 12-byte random IV (nonce), 16-byte authentication
tag appended to the end of the ciphertext.
- Before encryption, 0 to 4 random padding bytes were appended to the
UTF-8 seed phrase; the count is stored, strip that many bytes from the
end of the decrypted plaintext.
- Two passwords are involved: the benefactor's and the beneficiary's,
combined IN THAT ORDER into a single PBKDF2 input.
Version 1 format:
- Combined password = benefactor password + beneficiary password,
concatenated directly (no separator), UTF-8.
- The payload is base64. Decode it once to get a string of four fields
joined by "." (dots): base64(salt) "." base64(iv) "." base64(ciphertext
including tag) "." two-digit padding count (e.g. "03").
- Decode the three base64 fields, derive the key, AES-256-GCM decrypt
(no associated data), strip padding, interpret as UTF-8.
Version 2 format ("LE2." prefix):
- Combined password = benefactor password, then byte 0x1F (the ASCII Unit
Separator control character), then beneficiary password, UTF-8.
- Strip "LE2." and base64url-decode the rest (base64url: "-" and "_"
instead of "+" and "/"; pad "=" back if your decoder needs it).
- The decoded binary body, all multi-byte integers big-endian:
offset 0, 1 byte : version, must be 0x02
offset 1, 1 byte : KDF id, 0x01 = PBKDF2-HMAC-SHA256
offset 2, 4 bytes: PBKDF2 iteration count (uint32; reject values
outside 100,000..10,000,000 before deriving)
offset 6, 1 byte : padding length (0..4)
offset 7, 16 bytes: salt
offset 23, 12 bytes: IV (GCM nonce)
offset 35 onward : ciphertext with 16-byte GCM tag at the end
- AES-256-GCM decrypt with the first 35 bytes of the body passed as the
GCM associated data (AAD). A failed authentication tag means a wrong
password or a corrupted payload — it will not decrypt to garbage.
The decrypted plaintext is a BIP-39 seed phrase (space-separated English
words). Verify it against the BIP-39 word list, then follow standard
Bitcoin wallet recovery procedure with hardware you control.