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.

Seal opens nothing early, and Apple and we cannot open anything at all. (At a rule of one, the trust you place in each key holder is total; see the limits page.) Nothing we run can read, open or change your envelopes: 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. The one exception to trusting nothing of ours is the recipient web page (site/open): it is code this site serves, so the iPhone app stays the stronger way to open envelopes.

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.

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.

docs/PRE_AUDIT.md is the long version, written for a reviewer. The short version:

• 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. 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.
• Most tests only run at debug launch, on a phone, watched by one person. SecurityFixTests is not even registered, so it never runs at all. The key split and the countdown compile on their own, and anybody can run those: sh tools/run_core_tests.sh.
• Everything sits under one Apple developer account, including the CloudKit container with every sealed envelope in it. If Apple closes that account the storage goes with it. A capsule export is the only copy that lives outside.
• No reproducible builds. You cannot prove the binary Apple ships was built from this source.
• No cryptographic time lock, and there cannot be one without a trusted third party. The countdown is a signed public record that honest apps obey. M key holders plus the recipient could agree to ignore it. That is the trust the owner chose when they chose those people.
• The timestamp authority is a placeholder. docs/RECORD.md section 13 says why.
• The field arithmetic in the key split is not constant time. Shares are only ever handled on their holder's own device, so this was accepted rather than rewritten.
• Claim reasons and objection notes are stored in the clear.

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.

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 the device endorsements, every event's digest and signature, the links between events, the epoch commitments against what the owner signed, every key tap against its challenge, and the RFC 3161 tokens. Token signatures need openssl on the path.

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.

The most useful thing a stranger can do today is read, not write. Six files, in the order SECURITY.md puts them.

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.

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.

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

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.

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.

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

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.