Seal stores letters and passwords that unlock for family only after you die

A dead man's switch for personal secrets

A single developer has launched Seal, an iPhone and iPad app that holds encrypted letters, photos, voice notes, files and secrets such as bank passwords or wallet phrases, and unlocks them for chosen people only after the owner has stopped checking in. The project reached the front page of Hacker News as a Show HN post on 19 September 2026, linking to its GitHub repository. It is free on TestFlight, with an App Store submission filed for September 2026.

What it holds, and for whom

According to the project's README, Seal targets a gap in ordinary estate planning: a will passes through a court and becomes a public record, so it cannot safely contain credentials or anything meant to stay private. Seal's envelopes are meant to hold those instead, one per person, combining a letter, media, a file and the secrets themselves.

Identity is a passkey or a hardware security key, with no password, email address or recovery code, which the README argues leaves nothing for a phishing attempt to ask for. Recipients are enrolled in person: the two phones exchange public keys while standing next to each other, and each device thereafter rejects any different key presented under that name. An on-device assistant can interview the owner and draft the letter, or read an attached PDF and propose first steps for the recipient, and the README says that processing never leaves the phone.

How a release is triggered

The owner's ongoing job is simply to open the app now and then. The default rule allows any two of three key holders to start a claim after 90 days of silence, followed by 21 days of warnings and 14 quiet days; the owner chooses all four numbers, and each envelope can set its own thresholds, so a medical letter could open in days while the rest wait months. A single tap cancels a claim at any point, and cancellation deliberately works without the hardware key, so a living owner who has lost a key can still stop the countdown.

The cryptography splits keys with Shamir secret sharing over GF(256), uses hybrid X25519 plus ML-KEM-768 key exchange, and encrypts each envelope with its own AES-256-GCM content key. The app runs on iOS 18 and later on a single owner device, with no Android version; ML-KEM and the on-phone writing help require iOS 26.

No server, and a record anyone can check

Seal has no backend of its own: encrypted envelopes sit in Apple's iCloud inside the app's own container rather than the owner's personal storage, and key material stays on the devices. The README lists zero third-party dependencies, no analytics and no crash reporting. Pricing is a one-time purchase rather than a subscription, and holding a key or receiving an envelope costs nothing.

For verification, anyone holding part of an estate can export a capsule, a single JSON file with the full signed record, and check it with a standalone Python script that contains no Seal code and makes no network calls. It validates device endorsements as WebAuthn assertions, event digests and signatures, epoch commitments, key taps against the claim challenge, and RFC 3161 timestamp tokens. The README admits what the script cannot prove: completeness. Because the owner and several key holders write concurrently with no server to order events, a hidden entry surfaces only when capsules held by different people are compared, or through the timestamp tokens.

Limits the author lists first

Nobody independent has reviewed the cryptography or the code. The one design review before release came from the same AI assistant that wrote much of the code, and it found two issues that were fixed. The README's own advice is blunt: hardware wallet owners should not yet make Seal the only copy of a live seed phrase, and should start with details that do not require the twelve words at all, such as where the steel backup plate is and who to call first.

Further disclosed gaps include enrolling a hardware key on another person's behalf, which has never met real hardware and is the one path where private key material leaves a phone; a security-key compatibility matrix with no filled rows, leaving passkeys as the better tested route; tests that mostly run only on the developer's phone at debug launch, with one security test suite not registered so it never executes; no reproducible builds, so the shipped binary cannot be tied to the source; no cryptographic time lock, meaning the required key holders plus the recipient could act together to open an envelope early; a placeholder timestamp authority; non-constant-time arithmetic in the key split; and claim reasons and objection notes stored unencrypted.

Why it matters

Digital legacy is a genuinely unsolved problem: bereaved families routinely lose access to accounts, and secrets cannot go into wills because wills become public. Seal's answer, serverless storage, device-bound keys, in-person trust enrollment and a third-party verifiable release record, is a coherent architecture for that gap, and the standalone verifier plus reviewer-oriented documentation make the design inspectable in a way most consumer security tools are not. The project's own status page is also the caution: one developer, largely AI-written code, no funding and no independent audit, all stated plainly before asking anyone to trust it. Until an external review happens, Seal is an experiment worth watching rather than a vault for irreplaceable secrets.