How to open a vault —
with or without us.
If you've come here to recover a Lastnote vault, you're in the right place. Everything needed to open one — the format, the tool, the steps — is published, and it runs without us. A vault is meant to be opened years from now, perhaps after Lastnote is gone, so the procedure is built to need nothing from the company at all.
What you'll need.
Three things. No account, no internet, no permission from us.
- 1 The vault file. A
.quorumfile (it's a zip), or the unzipped vault folder. - 2 A threshold of keys. Short text strings like
3:a3f1…, one held by each trustee. You need at least K of them — the vault itself states how many. - 3 The Recovery Codex helpful, not required. The printed booklet that shipped with the vault — it carries this same tool and these same steps on paper.
The format spec, the reference tool, and a test vault — public, Apache-licensed, and reachable with no Lastnote account. Fork it, mirror it, keep a copy.
Two ways to open it.
Run the reference tool.
Python 3.9+ with the cryptography package. The decrypted
files land in ./recovered — that's the whole thing.
pip install -r reference/python/requirements.txt
python3 reference/python/lastnote_recover.py recover \
vault.quorum ./recovered --share-file shares.txt shares.txt is one key per line (the file of keys, one
per line). The
step-by-step procedure
documents exactly what the tool does, so you can verify it, not just trust it.
Hand it to a developer.
Most people opening an inheritance vault aren't engineers. That's expected. Give any competent software developer:
- the vault file,
- the keys you've gathered (at least K),
- the link to the recovery repository above.
Ask them to “run the reference recovery tool in this repo against this vault and these shares, and give me the decrypted files.” It's about an hour's work for someone who has never seen Lastnote before.
What the tool does, in seven steps.
Documented in full in
spec/recovery-procedure.md.
Every term is a standard cryptographic primitive a competent engineer
will recognise in any decade.
- Open
vault.json. It declares every algorithm and parameter required to decrypt the vault. - Gather any K keys of the form
index:hex_value. - Reconstruct the master key by Lagrange interpolation at
x = 0in the declared prime field. - Verify the reconstructed master key against its SHA-256 hash, also declared in
vault.json. If they disagree, one or more keys is wrong. - Derive the AES-256-GCM key by HKDF-SHA256 of the master key, using the salt and info declared in
vault.json. - Decrypt
index.encrypted. This yields the list of files in the vault. - Decrypt each file in
files/. Verify its SHA-256 against the value in the index.
Verify the method yourself.
Your own vault can't be tested without its real shares — but the method can. The repository ships an immutable fixture vault with its plaintext committed alongside. Recover it and check the bytes match:
python3 reference/python/lastnote_recover.py recover \
reference/fixtures/known-vault/vault.quorum ./out \
--share-file reference/fixtures/known-vault/shares.txt
diff -r ./out reference/fixtures/known-vault/plaintext # → no differencesIf those bytes match, the published tool decrypts the published format, independently of us. It's the same test — the dead-company drill — that blocks every Lastnote release if it ever fails. If you find a release that shipped without it passing, tell us and we withdraw it.
Open artefacts, made to outlast us.
- The format specification. Three short markdown documents describing the on-disk layout, the key encoding, and the recovery procedure. Readable in an afternoon.
- The reference tool. A single-file Python script of
around 320 lines that decrypts any conforming vault, using only the
standard library plus the widely-deployed
cryptographypackage. It is reproduced verbatim inside every vault's printed Recovery Codex — so it can be retyped from paper if every digital copy is lost. - The fixture vault. A vault committed with its plaintext, so anyone can prove the tool works (above).
It all lives in one public repository, under a permissive licence. Nothing here expires: clone it, mirror it to your own storage, commit it to an archive, or keep the printed Codex with your will. The Codex is paper-first on purpose — paper outlasts cloud accounts, USB sticks, and dead links.
What about quantum computers?
A vault that may need to open in 2050 has to be honest about cryptography that survives decades, not just years. Here's where we stand — without marketing dressing.
Encrypts the master key and every file. Grover's algorithm offers at most a quadratic speedup — halving effective strength to roughly 128 bits, which has no known feasible attack — and it parallelises poorly, so even vast quantum resources gain little. No migration is ever required.
Splits the master key among trustees. Information-theoretic security: it rests on no computational assumption a quantum computer could break. The maths is the maths, in any century.
Generated at seal time only if you enable remote key collection. Shor's algorithm on a large enough quantum computer breaks RSA. It is used only during the hosted key-collection flow; the in-person recovery above never touches it.
If you're planning past 2040
Two options, neither catastrophic, neither hypothetical:
- Disable remote key collection at seal time. The vault then carries no RSA material at all, and recovery is purely in-person — AES + Shamir + SHA-256, all quantum-safe.
- Re-seal when ML-KEM ships. When the WebCrypto API gains native ML-KEM (the post-quantum standard NIST published in 2024, also known as Kyber), Lastnote will swap the default recovery primitive. Vaults are versioned; old vaults stay readable forever.
For anyone with a horizon under ten years and no state-level adversary harvesting ciphertext to decrypt later, the current default is fine. Every vault carries these parameters with it, so a future reader can verify all of the above against the cryptography as it stood when you sealed.
“Given the published spec, the vault file, and a threshold of keys — could a competent developer in 2055 reconstruct the contents on a computer we cannot imagine?”
Every architectural decision is checked against that question. If the answer is yes, ship it; if no, simplify until it's yes. An inheritance tool that needs the company to still exist isn't an inheritance tool — it's a subscription with a sad ending.