Seal

Sealed envelopes for the people you leave behind.

Website · How it works · What it does not do · The objections, answered · Report a vulnerability

---

After you die, your will goes through a court and what is in it becomes a public record that anyone can look up. So the password to your bank, the phrase that opens your wallet, where the safe deposit key is, the combination, the thing you never told anybody: none of it can go in one.

Seal is where those things go instead. You write a small number of envelopes, one per person: a letter, photos, a voice message, a video, a file, and the secrets. You choose a few people you trust, face to face, and hand each a piece of one key. You set the rule for how the envelopes open after you are gone. Then you open the app now and then, and that is the whole ongoing job.

Nobody can open one early. Not Apple, not us. There is no Seal server: the encrypted envelopes sit in Apple's iCloud under Seal's own container (not your personal iCloud storage), the keys never leave the phones, and the record of who did what can be checked with a script that has no Seal in it.

If you own a hardware wallet, do not make Seal the only copy of a live seed phrase yet. Nobody independent has audited it. What your family cannot reconstruct without you is where the steel plate is, which wallet it belongs to, and who to call first, and none of that needs the twelve words. Start there.

Status, plainly

docs/GOTCHAS.md is the running list of things that went wrong and what they actually were. It is unflattering on purpose, and it is the first thing to read before debugging anything.

What is not done

Not a complete list. docs/PRE_AUDIT.md is written for a reviewer and the limits page has the rest.

• Nobody independent has reviewed the cryptography or the code.
• Registering a hardware key for somebody else has never met real hardware. It is the one place private key material leaves a phone, and it deserves the hardest look of anything here.
• Security keys are barely tested. The interop matrix in docs/SECURITY_KEY_TEST_MATRIX.md has no rows filled in. Passkeys are the better tested path today.
• Most tests only run on a phone, at debug launch, watched only by the developer. SecurityFixTests is not registered, so it does not run at all. The key split and the countdown compile on their own and anybody can run them: sh tools/run_core_tests.sh.
• No reproducible builds. You cannot prove the binary Apple ships is built from this source.
• There is no cryptographic time lock. Nothing can enforce one without a trusted third party, and Seal has none on purpose. The countdown is a signed public record that honest apps obey, so M key holders plus the recipient could act together to open early. That is the trust the owner chose.
• The timestamp authority is a placeholder. docs/RECORD.md section 13 says why the current free public one is not yet a defensible choice.
• The field arithmetic in the key split is not constant time, accepted because shares are only ever handled on their holder's own device.
• Claim reasons and objection notes are stored in the clear.

What it looks like

How it works

1. Register with a passkey or a security key. That credential is your identity. There is no password, no email and no recovery code, so there is nothing a phishing message could ask you for. Face ID alone is enough; a hardware key is optional.
2. Meet people in person. You add somebody by standing next to them, once. Each phone records the other's public key in that moment and refuses any different key served under that name afterwards, forever.
3. Write envelopes. One per person: a letter, photos, a voice message, a video, a file, and the secrets. You can start before you have added anybody, by typing a name. Seal can interview you and draft the letter, and it can read an attached PDF and propose "what to do first" steps. All of that runs on the phone, and none of it leaves.
4. Choose who can open them and set the rule. Any two of three, after 90 days of silence, then 21 days of warnings, then 14 quiet days, by default. You choose all four numbers. Each envelope picks its rule, so a medical letter can open in days while the rest wait months.
5. Tap Seal. Everything is encrypted on the phone before it leaves.
6. Open the app now and then. That is the check-in that keeps it closed.

If you go quiet past your limit, somebody you chose can start a claim. You are warned every day for weeks, then a quiet period runs. One tap from you ends all of it, and that tap never needs your hardware key: a living person who lost a key must not be declared dead by their own software. Only after all of that can keys be tapped, and each envelope then opens on the phone of the person it was written for. Nobody reads anybody else's, including the people who released it.

Check it without trusting us

Anybody holding part of an estate can export a capsule: one JSON file with the whole signed record. tools/verify_capsule.py is a single Python file with no Seal in it and no network access. It checks every device endorsement as a WebAuthn assertion, every event's digest and signature, that each event's link names an event that is present, that every epoch's commitments match what the owner signed, every key tap against the challenge naming that claim, and every RFC 3161 token. With openssl on the path it also checks the token signatures.

python3 tools/verify_capsule.py seal-capsule-XXXX.json --strict

What it cannot do is prove the record is complete. The owner and several key holders write to it at the same time with no server to order them, so hiding an event is only detectable by comparing capsules held by different people, or through the timestamp tokens.

tools/make_test_capsule.py builds a synthetic one, so you can watch it pass, change a byte, and watch it fail. The format is documented in docs/CAPSULE.md in enough detail to write a fresh verifier from scratch, deliberately, in case this project is not here.

Read the code first

The most useful thing a stranger can do today is read, not write. Six files, in the order SECURITY.md puts them. Between them they decide who can unwrap what, what one key holder learns alone, when a release is allowed, and whether a key was really tapped.

docs/PRE_AUDIT.md is written for a reviewer: where to attack in order, and the weak spots already accepted. It ends with the commands that reproduce the key split, a synthetic capsule and its verification on any machine, with no Mac and no phone. Those same commands run on every push.

The key hierarchy

Envelope Content Key   random 256 bit, AES-256-GCM, one per envelope
    listed in
Key Table              one per RECIPIENT, under its own random Key Table Key
    reachable two ways
    ├─ wrapped to the OWNER's devices
    └─ encrypted under the Estate Key, then wrapped to the RECIPIENT's devices
Estate Key             one per rule per epoch
    reachable two ways
    ├─ wrapped to the OWNER's devices
    └─ split by Shamir into N shares, threshold M, each wrapped to one
       key holder's devices

The same thing in the usual notation, for people who read that faster:

c_env      = Enc(m, k_env)                            one random k_env per envelope
Table_r    = Enc({k_env, ...}, k_table_r)             one table per recipient r
k_table_r  reachable two ways:
             Wrap(k_table_r, pk_owner)
             Wrap(Enc(k_table_r, K_estate), pk_r)     needs recipient's phone AND K_estate
K_estate   = Shamir split into s_1 .. s_N, threshold M
s_i        = Wrap(s_i, pk_holder_i)                   one piece per key holder

Wrap is X25519 plus ML-KEM-768 through HKDF-SHA256. Enc is AES-256-GCM with the estate, epoch and purpose in the AAD.

The people who release an estate recover the Estate Key and nothing else. It opens no envelope on its own: each key table still needs the phone of the person it was written for. A rule is a separate estate with its own Estate Key, so releasing the urgent envelopes reveals nothing about the rest.

Cryptography

All from Apple's CryptoKit and AuthenticationServices. Nothing rolled by hand.

Where things are

Documentation

Building

Xcode 26 to compile, an iPhone or iPad on iOS 18 or later to run it, and an Apple Developer account for the CloudKit container and the WebAuthn associated domain. New Swift files under Seal/ join the target automatically. The EstateEvent record type needs its estate field queryable in CloudKit, and Identity needs recordName queryable, in both the development and production environments.

Tests live in the app target under Seal/SelfTest/, because there is no test host for a passkey. They run on every DEBUG launch; a failure blacks the screen and prints which suite. The scheme has -SealDemoMode for a phone full of made-up envelopes and key holders, used for screenshots and demos.

Contributing

Pull requests are welcome for bugs, tests and documentation. Please read docs/GOTCHAS.md first, keep every new Swift file under the MPL notice, and do not add a dependency: there are none, and that is a feature the whole project rests on.

A finding goes to SECURITY.md if it lets somebody read, forge, release or stop something; anything else is an issue.

Paying for the audit

Seal has not been independently audited, and an audit by an outside firm costs more than a one-person project has earned. If you want to move that day closer, anything sent here goes toward it, and the audit report goes in this repo when it is done.

PayPal · Venmo

License

Mozilla Public License 2.0. File level copyleft: you may read, audit, run and fork this, and you may build something larger around it under whatever terms you like, but changes to Seal's own files have to be published under the same license.

MPL rather than GPL or AGPL on purpose. GPL family licenses conflict with the App Store's terms, which is why VLC was pulled in 2011 and why VideoLAN relicensed to MPL to come back. An estate product that cannot ship on the App Store is not a product.

Every source file carries the notice from Exhibit A, because MPL is decided per file and a file without the notice is arguably not covered.