Multi-key vault
Security posture

Sealed with proven cryptography.

Your vault is encrypted with AES-256 and split with cryptography that has stood unbroken since 1979. Below a threshold of keys it discloses nothing — not to an attacker, not to a court, not to us. That last part is deliberate: Lastnote is built so that we can't betray you, even if we were one day inclined or compelled to. We think that's the only honest posture for a tool asked to hold what matters.

What holds it shut

Three properties, stated plainly — then exactly.

Everything is encrypted before it leaves your device.

Your browser generates a 256-bit master key locally and encrypts every file and the index with AES-256-GCM. We receive ciphertext, or nothing at all — there is no point at which we hold your plaintext.

Your key never exists whole in any one place.

The master key is split with Shamir Secret Sharing into N keys (their formal name is shares) — pieces held by the people you trust, your trustees. Any threshold of K keys reconstructs it by Lagrange interpolation; below K, they reveal nothing about it whatsoever — information-theoretic secrecy, not merely computational hardness.

The lock outlives the locksmith.

The vault format is published in full. Any conforming tool decrypts a Lastnote vault using only standard primitives — with us, without us, or decades after us.

Section 01

The cryptographic primitives.

Lastnote uses only widely-deployed, peer-reviewed cryptography. Nothing is bespoke. Every primitive except the secret-sharing layer ships in the standard library, or the single most popular cryptography package, of every mainstream language — and the Shamir layer is a few dozen lines of modular arithmetic over a published prime, implemented identically in our Python reference and re-derivable from the spec.

Purpose Primitive Provenance
File & index encryption AES-256-GCM NIST SP 800-38D (2007); ubiquitous in TLS, disk encryption, messengers.
Key derivation HKDF-SHA256 RFC 5869 (2010); standard expansion KDF for derived sub-keys.
Filename obfuscation HMAC-SHA256 RFC 2104 (1997); standard authenticated hash construction.
Master-key verification SHA-256 NIST FIPS 180-4 (2015); the SHA-2 family.
Key splitting Shamir Secret Sharing Adi Shamir, “How to Share a Secret” (1979).
Shamir field arithmetic Prime field GF(2257−93) Documented in spec/vault-format.md; comfortably exceeds 256-bit secrets.
Hosted-recovery transport optional RSA-OAEP-2048 PKCS #1 v2.2 (RFC 8017). Used only to wrap keys in transit during hosted recovery; the one component not yet post-quantum — see the quantum note on Sovereign recovery.
Randomness OS CSPRNG via WebCrypto / secrets Browser WebCrypto API; Python secrets; macOS / iOS / Linux kernel RNGs.

Shamir Secret Sharing — the one piece that makes a multi-key vault possible — was published openly in 1979 by Adi Shamir, co-inventor of RSA. Below the threshold it discloses nothing about the master key: perfect secrecy, proven as an information-theoretic guarantee. (The files themselves rest on AES-256 — a computational guarantee: immensely strong, but a different and more conventional kind of promise than the key math.)

The constants, named.

  • AES-256-GCM — 96-bit nonce, 128-bit authentication tag. A fresh nonce is drawn from the OS CSPRNG for every blob and the index, so no nonce is ever reused under the master key — the one way GCM can fail.
  • HKDF-SHA256 — distinct info-strings derive the file-encryption key and the filename-HMAC key from the master key, so the two are cryptographically independent.
  • Field prime 2257−93 — chosen just above 2256 so every 256-bit master key has a unique representative; reduction can never alias one valid key to another.
  • SHA-256(master key) in vault.json — an integrity check that catches a mistyped key before decryption. It is safe to publish only because the master key is 256 bits of uniform randomness: there is no low-entropy secret to work backward from.
Where things live

There are three places your data can live. We sit outside all of them.

Your plaintext and your master key never leave your device. Only ciphertext and individual keys do — to the sealed file's resting place and to your trustees. Even when that file rests in our relay, we hold opaque bytes. Here is the whole map.

The trust boundary Your device holds plaintext and the master key, briefly and in memory. From it, ciphertext flows to the sealed file (kept on your own storage or, optionally, the Lastnote relay) and individual keys flow to your trustees. All three sit inside your control. Lastnote, the company, sits outside the boundary and only ever receives ciphertext and metadata — never a key, never your files. INSIDE YOUR CONTROL Your device PLAINTEXT Your files, in the clear Your master key, made here in memory — then gone encrypted split into keys The sealed file CIPHERTEXT vault.json — parameters, no secrets encrypted index + file blobs at rest: your own storage, or our relay Your trustees KEYS One key each Below the threshold: blank held apart, by people you choose ciphertext + metadata only LASTNOTE · OUTSIDE THE PERIMETER Sees ciphertext and metadata. Never a key, never your files.
Your plaintext and your master key never leave your device. What leaves is ciphertext — to wherever the sealed file rests, our relay included — and individual keys, to your trustees. Lastnote stays outside the boundary; only opaque bytes ever reach us.
What sits on disk

A sealed vault is ciphertext and a public manifest.

The sealed vault is a single file (or folder) with three pieces inside: metadata, an encrypted index, and a folder of encrypted file blobs. The vault.json manifest is human-readable and holds no secrets — it declares which algorithms, salts, and threshold were used, so any future recovery tool has everything it needs with no implicit dependence on us.

Inside a .quorum vault A .quorum vault contains a vault.json metadata file, an encrypted index, and a folder of encrypted file blobs. No plaintext is ever stored on disk. MyVault.quorum vault.json self-describing metadata — what algorithms, what salts, threshold index.encrypted AES-256-GCM-encrypted manifest of file names & hashes files/ encrypted blobs, named by HMAC of original filename e1aa4e60….enc f23695f7….enc ff6f5b2a….enc ← ciphertext only, no plaintext on disk ← filename hash leaks no information ← each blob has its own random nonce
The on-disk structure of a sealed vault. No filename, no file size, no piece of plaintext content is ever written outside the encrypted blobs. The metadata file is human-readable on purpose — it lets any future recovery tool understand the vault without our help.

What a sealed vault does reveal. Because each file is its own encrypted blob, anyone who sees the vault learns the number of files and the approximate size of each — encryption preserves length. Names and contents stay sealed (names become keyed HMAC hashes; contents are AES-256 ciphertext), and the manifest reveals only the parameters you'd need to recover. If the shape of your data is itself sensitive, archive or pad before sealing.

Concretely

Guarantees, not policies.

The items below are properties of how Lastnote is built. They are not promises we are choosing to keep; they are limits we could not work around if we tried.

We can

  • Help you design your distribution — who, where, how many.
  • Notify you if a planned check-in is overdue.
  • Coordinate the reunion of trustees at recovery time.
  • Publish the format spec, mirrored, indefinitely.
  • Be sued, acquired, or shut down without affecting your vault.
  • Publish transparency reports about any access requests.

We cannot

  • Decrypt your vault, even if compelled.
  • Read your file names, or what any file contains.
  • Hold enough keys to open your vault — not one, ever.
  • Reset, recover, or bypass a missing key.
  • Coerce your trustees — we hold no relationship with the people you choose.

The one exception is deliberate and still safe: with Concierge you can name Lastnote as a single trustee — one key, always below your threshold, so it opens nothing alone.

Section 02

The threat model.

We design against the adversaries below, and we state plainly what we do not protect against. A vault that overpromises is more dangerous than one that's honest about its edges.

We do protect against:

  • A passive observer of any single key. Nothing about the master key is recoverable from below the threshold.
  • A breach of our relay or cloud storage. It holds only ciphertext and the metadata above — never a key, never plaintext.
  • A government subpoena directed at us. We cannot decrypt your vault and cannot be compelled to do what is technically impossible; we publish any order we receive in our transparency reports.
  • Theft of a sealed vault file. It is ciphertext at rest — the file alone yields no plaintext, only the parameters the manifest declares by design.

We do not protect against:

  • An adversary holding a full threshold of keys. By design, that adversary is a permitted user of the vault. Choose your distribution accordingly.
  • A compromised device at seal time. A keylogger or screen recorder on the machine sealing the vault can capture the master key as it is generated; threshold cryptography cannot save a compromised endpoint.
  • A malicious or compromised web server serving backdoored JavaScript. Browser-delivered cryptography means trusting the code served on each load — for maximum assurance, verify the served code, or run the published reference tooling offline.
  • A key sent over an insecure channel. Distribution is yours to control; a key emailed in the clear is a key an interceptor holds. Wrap high-value keys to a hardware key.
  • Theft of your own keys, if you kept a set. An owner-editable vault gives you a second way in — your own threshold of keys, printed in the kit’s for-me/ folder. Anyone who gathers enough of those opens the vault, exactly as a trustee quorum would. Store them as separately as you would a trustee’s, or leave owner access off for a purely sealed vault.
  • Influence over when recovery begins. Anyone who controls your check-in channel can let the wellness timer lapse. They cannot open the vault — that still needs a threshold — but they can start the clock.
  • A coerced trustee. Threshold cryptography is not duress-proof; optional duress controls are an additional layer, not a primitive.
  • Loss of more keys than the threshold permits. The vault becomes unrecoverable — the deliberate property of the design.

What we deliberately don't do.

We don't verify death certificates, accept ID-document uploads, or ask notaries to attest. Each of those adds either false-positive risk — a vault opening while you're still here — or false-negative risk — a vault never opening when it should. We'd rather rely on the mathematics, the time, and the people you chose.

Section 03

Open, and tested end to end.

We don't ask you to trust our implementation on the strength of our reputation. It is published, and it is bound to a test that can't be faked.

  • The spec and a reference decryptor are public. A single-file Python script under two hundred lines decrypts any conforming vault, and every release is blocked unless that script can decrypt an immutable fixture vault committed to the repository — the test we call the dead-company drill.
  • Every implementation is cross-checked. The JavaScript web app is tested in CI against the reference Python on every release; any divergence fails the build.
  • Independent third-party audits are on our roadmap, and we'll publish the reports when they're complete.

How a vault opens with no Lastnote in the loop The spec + reference tool on GitHub

Seal what you can't afford to lose.

Create a vault
Feedback