What Legatus never has

Legatus never receives a vault owner’s passphrase and never holds a decryption key. Encryption happens in the browser before anything is transmitted, so the servers store ciphertext only. This is the constraint every other design decision follows from, and it is why some things Legatus could otherwise offer are impossible.

Legatus stores	Legatus never stores
Ciphertext of vault contents	Your master passphrase
The vault key, encrypted under your passphrase	The vault key in usable form
The vault key, encrypted for each nominee	Any nominee’s private key
Death certificates, in a private bucket	Anything that could decrypt a vault

Step 1 — Sealing the vault

When a Legatus vault is created, a random AES-256-GCM master vault key is generated in the browser. That key is then encrypted under a second key derived from the owner’s passphrase using PBKDF2 at 310,000 iterations. Only the encrypted form ever leaves the device.

The iteration count follows the OWASP recommendation for PBKDF2 with SHA-256. It exists to make guessing a passphrase expensive: an attacker who obtains the encrypted vault key must pay that cost on every single guess.

Step 2 — Nominee key exchange

Each nominee generates an RSA-2048 key pair when they accept their invitation. The master vault key is encrypted separately against each nominee’s public key, so every nominee holds their own encrypted copy. No nominee can read anything before a verified transition, and no nominee needs to be trusted with a shared secret in advance.

This is the step that makes the rest possible. The alternative — telling a nominee the passphrase now and asking them not to use it — protects nothing, because it depends entirely on that person’s continued goodwill for as long as the owner lives.

Step 3 — Confirming presence

A Legatus vault owner confirms they are alive at an interval they choose: monthly, bi-monthly or quarterly. Missing a check-in raises an alert to nominees. It does not release the vault. A missed check-in is treated as a signal worth investigating, never as proof of death.

Why this differs from a typical dead man's switch

Most consumer dead man’s switches release on a timer alone: miss enough check-ins and the secrets go out. That fails badly in ordinary circumstances — a long hospital stay, a lost phone, travel. Legatus uses the timer only to start a conversation, and requires humans to confirm before anything opens.

Step 4 — Verified transition

A verified transition is the Legatus release process. Two of the three nominees must confirm the owner’s death independently, an administrator must review an uploaded death certificate, and a 72-hour hold must elapse. All three gates are required; no single person can complete a release alone.

Gate	What it defends against
Two-of-three nominee confirmation	One dishonest, mistaken or compromised nominee
Administrative review of a death certificate	Confirmation without any documentary basis
72-hour hold	A release that is wrong but not yet noticed

Death certificates are stored in a private bucket. Access URLs are signed and expire after 15 minutes, and only administrators can generate them.

Step 5 — Release

After a verified transition completes, each nominee can decrypt the master vault key using their own private key and read the material assigned to their role. Personal messages are dispatched. Nominees receive what the owner assigned to them and nothing beyond it.

While a vault is open

A decrypted Legatus vault key is held in browser memory only, and is wiped after 30 minutes of inactivity. Returning after that requires the passphrase again. The key is never written to disk and never sent to a server in usable form.

What this design does not protect against · Definitions of the terms used here