The Semparo security architecture

Last reviewed July 19, 2026 · v2.2

Patent pending. The mechanisms described on this page are the subject of U.S. patent applications filed by Semparo (U.S. Provisional Patent Application Nos. 64/108,852 and 64/108,856). Read our patent pledge for what we will and will not do with them.

Semparo holds the most sensitive things a person can write down: seed phrases, a will, the map of what they own, and the words they want their family to have after they're gone. (For everyday accounts we hold the map: what exists, where it lives, and the lawful way for your people to claim each one.) This page explains, precisely, how the system is built so that no single party can open a vault early. Not a hacker, not a court order served on us, not a rogue employee, and not Semparo itself.

By "early" we mean before a release is authorized: before a quorum of the people you chose have sworn, in writing and under penalty of perjury, and presented their printed key fragments; before the waiting periods have run; and while your power to stop everything still stands.

It is written for the skeptical reader. Every design claim links to the public standard or vendor documentation behind it, and the last section lists what we deliberately do not claim.

The full cryptographic scheme is published for open review. If you want the formal version, the whole design is written up as a paper: read it and try to break it. It has not been peer-reviewed, and it lists the exact questions we most want answered.

The threat model: our own servers are the adversary

Most products defend the perimeter and ask you to trust what is inside it. A digital legacy vault cannot work that way, because the honest answer to "what if Semparo is breached, subpoenaed, or acquired by someone you would not have chosen" has to be: it does not matter.

So the design treats the Semparo server as untrusted. For your vault, it stores and moves four things only: encrypted content, encrypted (wrapped) keys, opaque half-shares of the release key, and routing metadata. The two invariants every layer below serves:

1. No false release. Nothing decrypts before the release protocol completes: a quorum of the people you chose, sworn and holding their printed fragments, the waiting periods run, and your standing power to stop it unexercised. When signals conflict, the system errs on the side of not releasing, because a wrongful release cannot be undone.
2. Zero knowledge. By "zero knowledge" we mean it the way the term is used for encrypted vaults: your content is encrypted on your device before it reaches us, with keys derived from secrets only you hold. We store ciphertext. A breach of our servers yields no readable content, and support staff have nothing to look at.

Level 1: keys are born on your device and never leave it

When you set a password, your browser derives keys locally using Argon2 (RFC 9106), winner of the Password Hashing Competition, in its recommended Argon2id variant: a memory-hard function designed to make large-scale password cracking expensive.

Two properties matter here:

• Strict key separation. The key that proves who you are to the server and the keys that open your vault are derived independently, with distinct salts and domain-separation strings (the derivations compose Argon2id with HKDF, RFC 5869). The server stores only a password verifier. It never receives the password, and no value it stores can be turned into a decryption key.
• Two factors for the master key. Deriving your vault's master key requires both your password and a random 32-byte Secret Key generated at setup, which you keep. A phishing victim's password alone opens nothing. A stolen device blob alone opens nothing.

The Vault Key itself is random, wrapped under your master key, and separately wrapped under a printed Recovery Code, so you can recover from a forgotten password without us ever being able to do the same. Unwrapped keys live in memory for the session only and are zeroized after use. Every encrypted blob carries a version byte, so algorithms can be upgraded without breaking old data.

Level 2: every item is sealed once, under its own key

Each item in your vault (a letter, an account record, a seed phrase, a video) gets its own random Content Encryption Key. Content is encrypted with AES-256-GCM, the authenticated mode specified in NIST SP 800-38D, with the item's identity bound into the ciphertext as associated data, so an attacker who controls the database cannot swap one item's ciphertext for another's and have it accepted.

The seal covers everything about the item: its content, its title, and even its type. Our server cannot tell a seed phrase from a poem, and no record on our side asserts what kind of thing any item is. The release-relevant facts the server holds about an item are the waiting time you chose for it and which of your people it is addressed to. That addressing is routing metadata, held so release can deliver the right sealed parts; what the item is stays sealed.

The content is sealed exactly once. The item key is then wrapped twice: once under your Vault Key (so you can read it whenever you sign in) and once under the release key described next (so your people can read it after you're gone). Large media files are encrypted under the same per-item key and stored as opaque blobs.

Level 3: the release key that nobody holds

This is the part that makes a legacy vault different from a password manager.

The Release Wrapping Key is a random 32-byte key that exists nowhere in complete form outside an authorized release. At setup, your browser splits it using Shamir's secret sharing, the 1979 threshold scheme with information-theoretic security: any 2 of 3 shares reconstruct the key, and fewer than 2 reveal nothing at all, no matter how much computing power is applied.

Each of the three shares is itself split in two:

• a server half, stored by us, opaque and useless alone, and
• a paper fragment, printed into a sealed letter for each KeyKeeper: the people you choose to hold them. Until a release is authorized, fragments never touch our servers. They are presented only at release, and the limits section below describes exactly how that moment is protected and the hardening still in progress for it.

Reconstruction therefore requires at least two KeyKeepers to physically present their fragments, plus the matching server halves. Our database, fully leaked, contributes nothing without the paper in your KeyKeepers' hands. The cryptographic core refuses any configuration with a threshold below 2, unconditionally.

Because any 2 of 3 shares suffice, one lost letter or one unreachable KeyKeeper does not brick the release. And if you ever replace a KeyKeeper, your browser re-splits a fresh key, which retires every old fragment at once.

Level 4: your signed manifest decides who receives what

Who gets which item is recorded in a manifest that your browser signs with a hybrid signature: Ed25519 (RFC 8032) plus ML-DSA-65 (NIST FIPS 204), and verification requires both to pass. The signing key is derived from your Vault Key; the public key is committed under the release key with an anti-rollback version counter.

At release time, the reconstruction environment verifies the manifest before anything is unwrapped. If the signature does not verify, or the manifest is missing items it should cover, there is no release. The consequence: even an attacker with full control of our servers cannot add a recipient, remove one, or alter a single byte of your directions. Only code holding your keys, in your browser, could have produced the manifest.

One honest boundary of the signature itself: it cannot stop a replay of an older manifest you validly signed, back before you changed your mind. The version counter defends against that, and pinning your latest version somewhere outside our own infrastructure, so that not even a full compromise of our servers could rewind it, is hardening in progress. Until it ships, this appears in the limits section below rather than in the guarantees.

Level 5: reconstruction happens inside attested hardware

When the release protocol finally authorizes a release (a sworn KeyKeeper quorum with their fragments, the waiting periods run, your veto unexercised), the reconstruction runs inside an AWS Nitro Enclave: an isolated compute environment with no persistent storage, no interactive access, and no network path except the one we define.

The enclave proves what code it is running through cryptographic attestation: a hardware-signed document of its exact measurements. The key that seals per-recipient material lives in AWS KMS under a policy bound to those measurements, so it is usable only by that exact, unmodified enclave code. The host machine it runs on, and we as its operators, are locked out by policy and by hardware. The release key and content keys exist in the clear only inside the enclave, transiently, and are zeroized when the operation completes. We have validated this attestation path on real Nitro hardware.

The release machinery: a state machine, not a switch

The cryptography above answers "can it be opened." A separate policy layer answers "should it be, now." One thing we never do in that layer: decide what happened to you. The protocol runs on what can be sworn to it and proven to it, and on nothing else. Opening a vault is a guarded state machine:

• It starts when you stop responding. The process begins when your proof-of-presence check-ins lapse (you choose the rhythm, and an escalation ladder of reminders runs first), or when someone close to you reports that it should begin. A report starts a process. It never starts a release.
• 2 of 3 KeyKeepers, under oath, with their fragments. Each confirming KeyKeeper signs a written statement under penalty of perjury, in the statutory form with place and date, and presents the printed fragment from their sealed letter. Confirmations without the physical key material move nothing.
• Cooldown that rewards agreement. A unanimous 3-of-3 confirmation waits a shorter cooldown than a 2-of-3, because disagreement is a signal.
• Your veto, on every channel. Throughout the waiting period we attempt to reach you on every channel you registered. Any response from you freezes the process. One reply stops everything. Staying in touch always wins.
• Waiting times you chose, per item. Every item carries its own hold, set by you when you sealed it, from available-at-authorization up to an additional 14 days for whatever you decide deserves the most caution. We cannot see what an item is, so we never decide its sensitivity; you do. Each recipient's access also matures on its own staggered schedule, so a single compromised moment cannot empty everything at once.
• We may ask for more. We can request supporting documents (a death certificate, for instance) or pause a release for human review when something looks wrong. These are discretionary safeguards layered on top of the protocol, and the protocol above never weakens when we choose not to exercise them.

Every transition in this machine is recorded in the audit trail described below.

Post-quantum, at every durable layer

A message recorded for a birthday thirty years from now must survive thirty years of cryptanalysis, including the harvest-now-decrypt-later pattern: adversaries recording encrypted traffic today to decrypt when quantum computers mature. That is CISA's framing, and it is the reason we did not wait.

NIST finalized the first post-quantum encryption standards in August 2024. Semparo's durable layers use them today, in hybrid constructions that remain secure if either the classical or the post-quantum half holds:

If hybrid post-quantum feels exotic: Signal ships it in PQXDH since 2023 and Apple ships it in iMessage (PQ3) since 2024, for messages far more ephemeral than a legacy vault. For thirty-year secrets it is not exotic. It is the floor.

Recipients: the honest trust model

Your recipients are grieving relatives, possibly decades from now. They cannot be expected to have kept a secret key safe since the day you set up your vault. So recipient access works differently, and we describe it exactly rather than rounding it up to a claim it does not meet.

At release, a recipient proves identity against the details you recorded, then receives two one-time codes over two separate channels (email and phone). The codes are HOTP (RFC 4226) values whose secrets live inside the enclave, and the enclave validates both internally, so a compromised host cannot forge a "valid" result. The recipient's browser generates a fresh hybrid X25519 + ML-KEM keypair for the session; the enclave seals the recipient's key material to that browser in the pattern of HPKE (RFC 9180), and decryption happens client-side.

The honest part: because recipients hold no durable secret, their protection is the enclave, the dual channels, and the release-window policy, not owner-grade zero knowledge. The exchange is relayed by our (untrusted) host, so this protection ultimately rests on the enclave's attestation rather than on anything the recipient holds; surfacing that attestation for the recipient's browser to verify directly is on the roadmap. An attacker who controls both a recipient's email and phone during the release window could impersonate that recipient for their entitled items. We consider that trade explicit and correct for people who cannot be asked to do key management, and we say it here so you do not have to discover it in the fine print.

The audit trail

Every consequential event (a report, a KeyKeeper's sworn confirmation, a state transition, an access) is appended to a hash-chained audit log: each entry binds the hash of the previous one, written in the same database transaction as the event itself, in a table the database refuses to update or delete from. Chain heads are checkpointed with the same hybrid post-quantum signature scheme as the manifest (under a separate, server-held signing key), so an external auditor can verify the chain's integrity without holding any symmetric secret of ours. The honest caveat: until checkpoints are anchored externally, a fully compromised server could forge future checkpoints, though never rewrite the past ones an auditor already holds. Anchoring to external timestamping services is planned, and we will say so here when it ships rather than before.

What we can read, and what we can't

Zero knowledge applies to your vault's contents. It does not apply to the handful of operational details we need to run the service, so we say exactly what those are and how each is protected.

At rest, our database holds no readable personal information. Two different mechanisms get us there:

• Your vault contents (documents, messages, videos, journal entries, seed phrases, even their titles and types) are zero-knowledge: encrypted on your device under keys only you hold. We never have the keys, so we can never read this, at rest or in operation. A breach yields nothing.
• The account and contact details we operate on (your email, phone, legal name, and date of birth, and the same for the KeyKeepers and recipients you designate) are encrypted at rest with AES-256-GCM before they reach the database, under a key held in our key-management service and never stored in the database itself. A stolen database, a leaked backup, a snapshot, or a SQL-injection read returns ciphertext, not a list of our users.

In operation, the only things our servers can read are these, and nothing more:

• Those contact and identity details, decrypted in memory only at the moment we need them: to log you in, send a one-time code, reach you during a veto window, and match a KeyKeeper or recipient at release. Here is the honest line: because we hold these keys, this is defense in depth against a database breach, not zero knowledge. A full compromise of our running servers could read these details while they are in use. What each person receives still stays sealed; that they exist as your contacts does not.
• Billing records (through our payment processor) and check-in signals (that a check-in happened; a daily responded-or-not bit if you enable the phone heartbeat, never location or usage).
• Routing metadata and operational logs: item identifiers, timestamps, sizes, and the standard web-service records every host keeps, including IP addresses. Never titles, never contents, never keys.

Independent review

This document describes the full design, and the deeper architecture documents publish alongside it. The client encryption core, the code that encrypts in your browser before anything reaches us, will be source-available: the repository goes public ahead of general availability, for anyone to read, diff, and audit, and this page links it the day it does. The license will not permit reuse, so it is not OSI open source.

The formal cryptographic scheme behind this design is written up as a paper and published for open review: read it, check it, and try to break it. It has not been peer-reviewed, and the paper itself lists the exact questions we most want answered.

Before we accept real vaults at general availability, we publish an assurance inventory you can check item by item: machine-checked formal verification of the release protocol, with the model published; an inventory of every cryptographic dependency and its own public audit; and NIST test-vector conformance with a public harness. A commercial third-party audit and penetration test are on the roadmap, funded by revenue, and those reports will be published in full, findings included. If you break something before then, we want to know: contacts@semparo.com, or through our coordinated disclosure policy.

What we do not claim

Trust comes from the limits as much as the guarantees:

• We never decide what happened to you. The only fact Semparo ever observes for itself is that contact from you has stopped. The people you chose swear to what they believe, under penalty of perjury; we record it, hold the waiting periods, and keep your veto open. When we ask for documents or pause for review, that is a discretionary safeguard we apply, never a judgment we issue.
• The release window is the moment of maximum trust in our infrastructure. Until a release is authorized, KeyKeeper fragments exist only on paper. At release, today, a fragment is presented through our server on its way into the attested enclave, which means a fully compromised server, in that window and only in that window, could see fragments and server halves together. Closing this is active hardening work: each fragment gets sealed in the KeyKeeper's browser to the enclave's attested key, so our server relays only ciphertext it cannot use. Note what this window is not: it opens only after the sworn quorum, the cooldown, and your standing veto, so it moves nothing early. We state it because a careful reader would find it, and because this page only ever describes the system as it is.
• Rollback protection is not yet anchored outside us. Your manifest carries a version counter, and the enclave checks it. But the record of "the highest version seen" lives in our infrastructure today, so a total compromise of our servers could, in principle, replay an older manifest you had validly signed before a change of mind. Anchoring the counter externally, so that not even we could rewind your decisions, is in progress, alongside the audit-checkpoint anchoring below.
• No commercial audit has happened yet. It is a roadmap milestone funded by revenue, not a launch gate. What gates real user data instead is the assurance inventory above, each item published for you to check. Until every item is live, treat this page as a design you can check, not a certificate.
• The production enclave deployment ships with general availability. The attestation path is validated on real Nitro hardware; the always-on production enclave, serving real releases, is a pre-launch milestone, not a today fact.
• Your operational details are encrypted at rest, not zero knowledge. Your email, phone, name, and date of birth (and your people's) are encrypted before they touch our database, so a breach of storage returns ciphertext. But we hold those keys and decrypt in memory to run the service, so a compromise of our live servers could read them. Only your vault contents are zero knowledge.
• Recipient access is enclave-trust, not owner-grade zero knowledge, as described above.
• Two of your KeyKeepers plus Semparo could, together, reconstruct your release key. Every threshold scheme has such a minimum coalition; ours requires two of the people you personally chose to conspire with us. Any smaller coalition, including all of Semparo alone, gets nothing, and the veto window means any attempt alerts you first, while you can still stop it.
• SMS is the weakest channel we use. One-time codes ride email and SMS today; SIM-swap attacks are why release access requires both channels, and stronger authenticators are on the roadmap.
• If you lose your password, Secret Key, and Recovery Code, your vault is unrecoverable. By us too. That is the design working, but it puts real responsibility on you.
• Continuity through a company wind-down is contractual, not cryptographic: paid retention funds your vault's survival and release; the cryptography cannot conjure availability if the infrastructure is gone.

References

Argon2id, RFC 9106 · HKDF, RFC 5869 · AES, FIPS 197 · GCM, NIST SP 800-38D · X25519, RFC 7748 · ML-KEM, FIPS 203 · Ed25519, RFC 8032 · ML-DSA, FIPS 204 · HPKE, RFC 9180 · HOTP, RFC 4226 · Shamir, How to Share a Secret (1979) · NIST post-quantum standards announcement · CISA on quantum readiness · Apple iMessage PQ3 · Signal PQXDH · AWS Nitro Enclaves · Nitro Enclaves attestation