The Semparo cryptographic scheme: published for open review

Last reviewed August 2026 · v1.1

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).

Semparo's whole promise rests on one claim: 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. A claim that strong should not be taken on faith. So we wrote the scheme down as a formal paper and we are publishing it here for anyone to read, check, and try to break.

This is an open-review invitation, not a certificate. The paper has not been peer-reviewed. We are asking the cryptographic community to review it, and the last section lists the exact questions we most want answered. If you find a flaw, we want to hear it before real vaults exist, not after. Reach us at contacts@semparo.com, or through our coordinated vulnerability disclosure policy.

The design and its trade-offs are described in plain language on our security architecture page, and our commitment to keep the underlying patents from being used against independent researchers and open-source implementers is on the patent pledge page.

Read the full paper

The complete formal write-up, with the construction, the security arguments, the post-quantum analysis, and the figures, is a downloadable document:

• Threshold-authorized, post-event selective disclosure (full paper, PDF), revision 6.

The sections below reproduce the plain-language summary and the abstract, and restate the reviewer questions in plain language, so you can decide whether the full paper is worth your time. Revision 5 tightened several descriptions to match the built system precisely: a standards label on the session channel, how the secure chip obtains the owner's key, the form of the owner's cancel action, and the lifetime of the release key during unlocking. Revision 6 (August 2026) is a presentation revision: the PDF is retypeset with LaTeX, the two figures were corrected, and the prose was lightened. The construction and the cryptography are unchanged in both.

What the paper describes, in plain language

The scheme locks up digital information so that:

• Only specific people you choose can ever see it, and each piece of information can be addressed to a different set of people.
• Nothing is revealed until a particular event happens (the paper keeps the event abstract) and a small group of trusted helpers agrees to unlock it. No single party, not even the company that stores the data, can open it early or alone.
• The company storing the data can never read it. It only ever holds scrambled bytes. Even if its servers are completely compromised, the contents stay secret.
• It stays secret even against future quantum computers. This matters because the data may sit locked away for years before it is ever opened, and an attacker can record the scrambled bytes today and try to crack them later.

The cast. An Owner seals the information. Three Agents are the trusted helpers. Any two of the three can authorize an unlock, so losing one does not lock things up forever, but no single Agent can act alone. The chosen recipients are the Consumers. A tamper-proof secure chip (a "TEE") does the actual unlocking inside a sealed environment that even the company's own operators cannot look inside.

How it works, in three steps:

1. Sealing. The Owner scrambles each item with its own key, then locks those keys so only the Owner (now) or the group of Agents (later) can recover them. The master unlock key is split into three pieces, one per Agent, and each Agent's piece is itself split in two: half kept by the company, half kept offline by the Agent. So neither the company nor any Agent can act alone.
2. Unlocking. When the event occurs and enough Agents agree, the secure chip reassembles the master key, but only after a waiting period during which the Owner can cancel. That window is what stops a false alarm, or a dishonest group, from forcing an unlock. The chip then prepares each recipient's personal keys.
3. Receiving. Each recipient proves who they are with one-time codes that are checked inside the secure chip, and the chip hands them their keys over a quantum-safe channel. They decrypt and read only what was meant for them, on their own device, never on the company's servers.

The weak points. Recipients carry no secret in advance, so their first sign-in leans on codes the company delivers, which is strong against an honest company and weaker against a fully malicious one. The paper explains how to harden it. And the whole design trusts that the secure chip is genuine, which each recipient's device must verify.

Abstract

We describe a scheme by which a single Owner seals a set of data items, each with an individual audience of designated Consumers, such that: (i) no item is disclosed until an externally-attested Trigger Event occurs and a threshold t of n Agents authorizes it; (ii) an untrusted Storage Provider that holds all ciphertext learns nothing about item content; (iii) after authorization, each Consumer recovers exactly the items addressed to them, and nothing else; and (iv) all data held at rest is post-quantum confidential. Disclosure is mediated by an attested Trusted Execution Environment (TEE) that prepares per-Consumer keys in a single reconstruction burst and delivers each Consumer's keys lazily, on first contact. We give the construction, a threat model with four security goals, a security argument for each, a post-quantum analysis layer by layer, and a statement of the scheme's limitations. We solicit review of the threshold and two-factor reconstruction argument, the signed-audience anti-rollback design, the hybrid-KEM session channel, and the honest-but-weaker Consumer authentication tier.

Scope of the "zero-knowledge" claim. We mean content zero-knowledge: the Storage Provider learns no item plaintext or content key. Routing metadata (which Consumer is addressed by which item, and Consumer contacts) is deliberately visible to the provider. We do not claim to hide the relation's existence.

Help us break this: the reviewer questions

These are the open questions the paper asks directly. They are the fastest way to spend a review where it matters most to us. If any of these has a clean answer we have missed, that is exactly what we are publishing to find out.

1. The no-false-disclosure argument. Is the composition of 2-of-3 Shamir sharing with the per-share XOR two-factoring sound? And on key separation: the signing key is derived from the vault key by HKDF-Expand under a dedicated info label while the vault key also keys the encryption wraps. Is expand-with-distinct-info clean separation, or should each purpose get an independent extraction?
2. Anti-rollback. Is a signed audience graph with a monotonic version pinned inside the secure chip enough against a replay or rollback by the storage provider, or do we need a stronger freshness anchor such as a hardware monotonic counter?
3. Hybrid KEM. Is combining the X25519 and ML-KEM shared secrets by hashing their concatenation an adequate combiner for binding and robustness, and is hybridizing the session seal worth it given it is ephemeral?
4. Release-key lifetime. The scheme zeroizes the release wrapping key within the single reconstruction burst and keeps only per-recipient keys for the disclosure window, rather than holding the release key reachable throughout. Is that narrower per-recipient exposure acceptable, and is the per-recipient key indirection the right way to avoid retaining the release key without sealing eagerly to a future session key?
5. The recipient one-time-code tier. Given recipients pre-share nothing, is an in-chip HOTP plus provider-delivered codes the best achievable, and is enrolling a durable credential (such as WebAuthn) on first contact the right hardening path?
6. The key-wrap choice. The content-key wraps use AES-256-GCM with the owning identifiers bound as explicit associated data and a fresh random nonce per wrap. Is this defensible against AES-KW or a misuse-resistant mode, from a nonce-misuse standpoint?

What comes next

Read the full paper (PDF) and send anything you find to contacts@semparo.com. For a vulnerability in the running service rather than the paper, use our coordinated disclosure policy. Reviews that only clarify are folded in for free. Any new mechanism a reviewer prompts goes into a patent filing before the revised paper publishes, the same rule we hold ourselves to throughout.