Sealbox
In messages, email, or posts, you compose a Sealbox in a protected space, before it touches any messaging app: a sealed object that travels as ciphertext over any channel that can carry it. The channel you send it through only ever sees the sealed box.
The channel protects the route. Sealbox protects the content — including at rest, on the device, where the channel ends.
Encrypted messengers protect messages on the way between devices. But the content's life doesn't end in transit — it sits on the endpoint, where the messenger's protection stops. Sealbox seals the text itself, before any channel touches it, and keeps it sealed at rest behind your biometrics. It adds to any channel; no channel adds to it. The question "can I trust this app with my words?" stops mattering — the transport never held them in the clear. The guarantee is intrinsic: because the text leaves Sealbox already sealed, it doesn't depend on the apps you send through. We call that self-sovereign text: the protection belongs to the text itself, wherever it goes.
Honest scope: channels generate metadata (who, when, how much) — that's the route's domain, and no content layer can hide it. Sealbox seals what's inside. The limits are spelled out below, not buried.
Encryption here isn't a setting you forget — it's an act you take. You open Sealbox with a clear purpose — to protect something sensitive — and what comes out is a Sealbox: a sealed object that stands on its own, not a property of some channel.
Open Sealbox and write in its composer — no third-party keyboard, dictation blocked by default, the text stays inside Sealbox until you seal it (with the limit of server-based dictation, stated further down, and one exception, by design: the drafts list shows, outside the capture shield, the first line of drafts never encrypted with a personal key).
Pick the contact and seal. Your keys release only to your biometrics (Face ID or Touch ID). You've generated a Sealbox — encrypted, authenticated, and bound to its reader. By default it's view-once: it opens one time, and the key dies on reading.
Share it to any app — WhatsApp, Mail, a public post. The channel only ever carries ciphertext.
To read one, select the received block → Share → Sealbox — or point the camera at it, if it came as a QR. To reply, the extension leaves the reply ready and you open Sealbox yourself — its composer opens with the recipient already set. Inside the app, one tap opens it.
Sealbox isn't a pile of features. There are two things you actually need — and the rest exists only because those two demand it.
Seal text for exactly one person and send it through any channel: message, email, a post. Only they can open it — and, by default, only once: in view-once, each message's key dies on reading. This is the core.
Some text has no recipient: passwords, codes, private records. A personal key — separate, held only by you — adds an extra layer of protection over what you keep in Drafts, opened right in the app. Not for encrypting and keeping in another app, where every read means decrypting again — for keeping it here, behind a stronger lock.
Both of those need somewhere safe to write and hold the text — and neither can live in a third-party keyboard or a notes app, which is exactly where text leaks. So:
In Sealbox's own composer you write what you'll send sealed, and hold the content your personal keys protect — encrypted at rest, behind your biometrics. We call them drafts, not notes, on purpose: Sealbox is not a notes app. A draft is text on its way somewhere, or text you're deliberately keeping sealed — both need a secure place, never loose and unprotected.
And the 1:1 reaches one person. When the same content needs to reach more:
Hand a key to whoever you trust; everyone who holds it can read the same sealed content — and holders who've unlocked writing can write to it. No managed group, no admin, no server choosing members — just a key, and the rule of any secret: trust who you share it with.
And two functionalities run across all of the above:
Rotate your operation keys whenever you want; the new one spreads on its own, inside your next messages — no server. And the old key's timing is yours: Delete now erases it from this device instantly.
Messages and drafts: it all sits sealed behind your live biometrics. On a lost phone, even one already unlocked once (AFU), the content stays sealed — an engineering guarantee with no known public bypass, not a formal proof.
Every message ends up somewhere, and stays there: on the device, in app databases, in backups, in every copy along the way. The device is where your text spends most of its life — and where it's most exposed.
A lost or stolen phone that's been unlocked at least once (the "After First Unlock" state) gives up most apps' content to data-extraction tools (like Cellebrite or GrayKey) even with the screen locked — the screen lock doesn't re-seal the data underneath, and the channel's protection ended long ago. The text is sitting there, in the clear, waiting.
Sealbox, instead of trusting a channel, seals the text itself and ties the key to your live biometrics — no passcode fallback, and no keeping content reachable in the background the way apps that receive notifications must. On the device — even lost, even in AFU — the content stays sealed. That is an engineering guarantee with no known public bypass, not a formal proof. Sealing the content (not the channel), the biometric gate, being serverless, receiving nothing in the background: it all exists to make that true.
And it covers the whole app — including your drafts, which sit sealed at rest behind your biometrics. That's the difference from a notes app: here no saved draft sits in the clear on disk. It's why drafts exist: to give your text the protection it needs — not to compete with notes apps.
No character limit here, unlike a store page. This is the part worth reading before trusting anything with your words.
Your identity is a bundle of six public keys — three encryption KEMs, two signing keys, and one composite root identity that certifies the rest (seven in Hardware mode, which adds an ML-KEM-768 key held in the Secure Enclave) — generated automatically when you start. Every message is encrypted and authenticated, recipient-bound: your contact knows it came from you and was meant for them. An epoch message and the one that opens a session carry your identity's signature (encrypt-then-sign); the ones that follow inside the session are authenticated by the session's own keys — which only the two of you hold.
HPKE with X-Wing (X25519 + ML-KEM-768 hybrid) + ML-DSA-65 signatures (FIPS 204). Confidentiality and authenticity resist future quantum attacks — protection against "harvest now, decrypt later". Larger payload (~6k chars in epoch; in view-once, ~10k for the message that opens the session and for the ones sent before the contact first replies — up to ten in all —, then from ~2k chars to ~7.5k; fits messengers, email, pastebins — not SMS).
HPKE with P-256 living inside the Secure Enclave + Ed25519 signatures. The decryption key never reaches app memory — the chip does the work. Compact payload (short posts; over SMS, use epoch).
HPKE with Curve25519 + ChaCha20-Poly1305 + Ed25519 — the modern stack trusted by WireGuard and age; HPKE's internal KDF is still HKDF-SHA-256. Compact payload, minimal assumptions (over SMS, use epoch). One condition, here and in Classic: a message to a contact still on your old key carries the new certificate — about 9,000 characters in Compact — until they reply (after a key update).
Exchange keys face-to-face with an animated QR (the invite is ~14.7 KB in software mode and ~15.9 KB with hardware keys — too big for one code, so it plays as frames), or share remotely through any channel. No keyservers, no .asc files, no key-signing parties.
One invite, one contact. Pairing is mutual — each side hands its bundle to the other — and what you hand over is an invite: your identity plus single-use opening keys, signed on the spot. Every QR display or export generates a fresh invite, good for one person only and for 30 days: whoever uses it first keeps it, and a second contact arriving with the same invite is refused — they ask for a fresh one. Those opening keys are what let the very first message already go out as view-once.
Trust on first use, with verification. A remote contact works immediately, visibly marked "unverified". Each of you has your own 13-word security code, derived from your own root identity (26 words in all), and the two of you compare them whenever convenient — and the marker flips. Routine key rotation is certified by the root identity and never triggers a false alarm; only an actual identity change does.
It's the 1:1 default. Between you and each contact Sealbox keeps a session: the key advances with every message, and each message's key is destroyed when the message is opened. Reading one message never reopens the ones before it: whoever gets your keys later — even by forcing your biometrics — finds the present of the conversation, not its past; the key to what's already been read no longer exists in the app. Paste the same block again within 24 hours of reading it and it answers "Message already read". The first message already carries content and already goes out this way — it uses a single-use opening key that came in the contact's invite and is erased on reading — and with every round of the conversation the keys renew through the mode's KEM, so a session also heals from an exposure (post-compromise security). No server: the state lives only on the two devices, encrypted at rest under a key that changes on every write.
In any order, with two stated limits. Pairing is the whole setup: once the two invites are exchanged, any of the first 10 messages of a new conversation can be the first one opened — there is no inaugural message that has to arrive first. Out of order, the app opens any of the next 10 messages, in any order; further ahead it doesn't open the message and tells you how many earlier ones are still unopened — open them, and it opens. And a skipped message keeps opening for up to 24 hours, and only while the conversation hasn't advanced two rounds.
Epoch stays, by choice. When the recipient needs to reread months from now, turn view-once off for that message: it goes out in the epoch regime you already know, signed, readable for as long as the keys exist. Signed in the open also means attributable: whoever holds both public identities can check whose epoch block it is; in view-once the signature does not travel in the open. The choice belongs to the writer, message by message; the reader sees, on each one, which regime protected it — and the app never switches regimes silently: if no session can be opened with that contact, it says so, and an epoch message only goes out if you tell it to.
The limits, stated plainly. The guarantee holds from the moment of reading, not of sending: what hasn't been read yet stays readable to whoever holds the keys. Out-of-order messages open within a short window (any of the next 10, for up to 24 h); outside it, ask for a resend — and with no server there's no receipt: the sender doesn't learn that a message was refused. Inside a session, messages are authenticated by the session's keys, not by your signature: only the two of you could have written them, and neither can prove to a third party which one did. Restoring a backup or switching phones restarts sessions from scratch — no backup carries what opens them. And destroying the key is what the platform allows: flash memory doesn't guarantee physically erasing a residue — what remains stays encrypted under keys bound to the Secure Enclave and your biometrics. Out of scope: shared keys (durable by nature), SMS (a session opening doesn't fit), and anything you choose to send in epoch.
The same animated QR that exchanges keys also carries the sealed message: turn on "Generate QR" in the composer and the Sealbox comes out as a code on screen; on the other side, "Read QR" points the camera and opens it — no pasting, no network at any point. A message crosses in seconds: 68 KB, measured on device, took three. It's what lets two Sealbox phones work as an off-network pair, when that's what the moment calls for.
And it bridges, both directions. A block that arrives by paste and doesn't open on this phone can be shown as a code instead: the phone it was meant for points its camera and reads it, and the phone in the middle never held anything but ciphertext. Going the other way, a phone can read someone's pairing invite and hand it onward without adding that contact itself — which is how a phone you keep off the network reaches a person who isn't in the room. Fits a sealed message up to 128 KiB; beyond that, it travels as text.
You write in Sealbox's own composer: the plaintext is born there — no third-party keyboard (which would need Full Access), dictation blocked by default, predictions off. What you keep persists sealed, and a draft can take on the extra layer of a personal key whenever you want. Nothing leaves until you seal it. One exception, by design: the drafts list shows, outside the capture shield, the first line of drafts never encrypted with a personal key.
Create as many named personal keys as you want — each one is an extra layer of protection over what you keep in Drafts, with a key only you hold (no recipient; the key itself authenticates). Committing authenticated encryption, no KEM and no signature. Each key is either recoverable (travels in your backup, migrates to a new phone) or device-bound (never leaves; irreversible choice). Deleting a key is crypto-shredding: everything it ever sealed becomes permanently unreadable, no cleanup needed — fully for a device-bound key; a recoverable one still opens from any backup that holds it, until that backup is gone.
A symmetric key you hand over through the 1:1 channel itself (inside a signed SBX1, so the recipient knows who it came from): whoever holds it can read the same sealed content — and write to it, if they've unlocked writing. It isn't a managed group — no admin, no "remove", no revocation. Whoever has the key can use it and pass it on, so the rule is the rule of any secret: trust who you share it with. Want a different set of readers? Make another key.
Backup is off by default. When you turn it on, Sealbox encrypts the package end-to-end before it touches your iCloud — Apple stores opaque bytes. The 24-word recovery phrase (256 bits) is the single secret that reopens it on a new device — it draws on the BIP-39 word list, but the phrase is Sealbox's own and is not meant to be imported into a hardware wallet; there is deliberately no human password, because a guessable password would reopen the offline brute-force door that the phrase closes. After a restore, a contact is marked "to confirm": a message signed by them is held back, and sending to them is blocked, until they answer a new invite from you — which guards against anyone holding a contact's old key. If iCloud is unavailable, the app tells you and offers manual export — it never fails silently.
Rotating your operation keys is a fresh start, in case one was ever exposed: it gives post-compromise security — from the rotation onward, everything is safe again (the "cure"). The new key reaches your contacts on its own, inside your next messages — no server. If there's never a reason to rotate, the only routine is renewing the operation certificate: it's valid for one year, the app asks you to renew it with a Face ID confirmation as it nears expiry, and the new one reaches your contacts inside your messages for the following 30 days.
It's the price of serverless: with no server, nothing pushes the update for you. In exchange for trusting no server at all, distribution rides your messages and when to rotate is your call — a responsibility a server-backed app would carry instead.
Advanced (elevated risk): rotation only pays off when there's a reason — suspected exposure, or periodic hygiene under a severe threat model. With no threat to recover from, rotating for its own sake buys nothing. What locks the past is deleting the old key, and every copy of it (forward secrecy for that epoch). By default it's kept, for contacts to reach you through your next messages. But the timing is yours: Delete now erases it from this device instantly. The app lists who's still on the old key and warns you plainly — what those contacts encrypt to it becomes unreadable until you update them; send each one a message, it already carries your new key.
This is the epoch regime: here forward secrecy is per-epoch, when the old key is deleted. Per-message forward secrecy belongs to view-once (above), the 1:1 default — the two regimes coexist, and rotation serves both.
Decryption keys live behind biometryCurrentSet — only your current biometrics release them, enforced by the Secure Enclave itself. There is deliberately no passcode fallback: a passcode can be observed, guessed, or compelled in ways live biometrics cannot. The Classic-mode key lives inside the Enclave; your contact graph (names, trust state) is encrypted under a biometric metadata key; and the app keeps zero historical logs. When the app locks or goes to the background, nothing your biometrics opened stays in the clear in its memory: the composer text and the message you were reading are kept sealed, and the lists of contact names, key names and draft titles leave memory; after Face ID they come back as you left them. If the app sits untouched past a set time, it covers the screen and locks the keys again, and only Face ID reopens it; the extension's read sheet has no such deadline — closing the message is up to you. Screen capture is designed in too: the text sits in the layer iOS uses for password fields, and a protection screen is meant to cover it while a recording or mirroring is on. For screenshots, we don't promise that the capture can't take the text. Recovery when biometrics fail permanently: restore from backup with your phrase.
Sealbox refuses your passcode as a way into its own keys — that's the paragraph above, and it stands. But the device passcode does a job no app can do for you: it is what stands between a phone that left your hands and the data-extraction tools. Everything here rests on the Secure Enclave, and the Enclave rests on the one secret you chose yourself.
Why it isn't just another password. Your passcode is tangled with a key fused into that chip at manufacture, so a guess can only be tried on that one phone — Apple calibrates each attempt to roughly 80 milliseconds. The problem can't be copied to a GPU farm or spread across a cloud; it runs at the speed of one device, one try at a time. The chip throttles repeated failures in hardware, and wipes the device after ten of them if you ask it to. That is why passcode brute force has no publicly known method on A14 and later.
Where your choice decides the outcome. The one documented path past all of that is the Enclave itself being broken open — a nation-state-grade attack on silicon, with no public key extraction from A12 or later despite the data-extraction industry's continued efforts. Suppose it happens anyway. The hardware throttle is gone, and what remains is the arithmetic of what you chose: six digits is a million possibilities — at 80 milliseconds each, less than a day. A high-entropy alphanumeric passcode is not a day, and not a lifetime — the search stops being something anyone finishes. That last door is closed by arithmetic instead of by our promise.
And it stacks with the layer Sealbox adds. Someone who knows your passcode still doesn't open a Sealbox: the keys release only to your currently enrolled biometrics, and enrolling a new face or finger invalidates them rather than granting access. So the passcode defends the device against those tools; the biometric gate defends the content against someone who has the passcode; and view-once means the messages already read have no key left anywhere to find. Of everything you can do for the guarantees on this page, a strong alphanumeric passcode is the one with the most leverage — in Settings › Face ID & Passcode.
Honest about entropy: length is not strength. A passcode you invented and can recite carries far less randomness than its character count suggests, and the people who break passcodes model exactly how people invent them. What buys the ceiling is randomness you didn't choose — words drawn by dice or by a generator, memorized afterwards.
Backup is a trade either way. With a backup, your identity survives a lost phone, and a copy of it exists. Without one, no copy exists, and nothing comes back. When the stakes call for the second, Sealbox has a maximum configuration, and it is worth stating exactly what it buys and exactly what it costs.
The mechanism has a name: crypto-shredding. Destroy a key and everything it ever sealed becomes unreadable at once and permanently, without the content itself being touched. It's the same mechanism that makes deleting a personal key erase everything that key protected. View-once applies it per message: each message carries its own key, and that key is destroyed the moment the message is read.
The configuration. Keep view-once on, which is already how 1:1 behaves. Leave backup off, which it already is by default. Set an alphanumeric passcode. That's the whole setup, and each of the three does a different job.
Why backup off is a condition, not a second layer. Destroying a key only produces irrecoverability if every copy of it dies with it. A backup keeps a copy. So backup off isn't one more wall standing beside crypto-shredding — it's what makes crypto-shredding mean anything at all. The other thing it does is the one people notice first: with no backup there is no encrypted package in your iCloud for anyone to demand, and no 24-word phrase to store, to lose, or to be compelled out of you. An entire class of attack stops existing, by construction.
What it guarantees. What remains in flash memory after a key is destroyed is residue wrapped by the chip's own key hierarchy, and every way to reach it is closed in turn: someone forcing your biometrics operates the chip rather than breaking it, and the key they'd need no longer exists; someone desoldering the memory gets ciphertext, because the chip stayed behind; someone breaking the chip itself still meets your passcode, and a high-entropy one does not yield. That is the chain, and its links are not equally certain. The first is an engineering guarantee, not a formal proof: the key no longer exists, so there is nothing to force out of anyone. The second follows from how the chip is built, and the note below says exactly how far that goes. The first two hold without the passcode mattering at all; the passcode is what covers the third.
What it costs — said in full. Backup off means no recovery. Lose the phone and your identity is gone: your contacts pair with you again from scratch, and everything held on that device goes with it. We won't dress that up. What you are buying is the absence of a recoverable copy — and a recoverable copy is precisely what recovery is. The two cannot both be true, and choosing is the point.
Where it stops, today. The guarantee begins at reading, not at sending: a message you haven't opened yet is still readable to whoever holds the keys. Epoch messages and drafts you deliberately keep are content you chose to keep — they stay until you delete them, and the ceiling doesn't cover what you asked to preserve. And the configuration is something you set by hand; Vault Mode (further down this page) gathers part of it into one profile, and the panic gesture crypto-shreds everything at once — both are in the app.
Honest precision: against a coerced unlock, the guarantee asks nothing of the chip beyond the key being gone. Against removing the memory chip, it follows from the chip's anti-replay design, which Apple does not publish — so we state it as the mechanism's consequence, a strong one, not as a proof.
Read it as a single system: every capability on this page exists to govern where text in the clear can exist — from the moment it's born to the moment it dies. And all of it is in the app on day one — what's still being built lives in its own section near the end of this page, clearly marked.
Text is born in Sealbox's own composer — no third-party keyboard, dictation blocked (you can allow it, and the block comes back when the app is closed and reopened), predictions off. Nothing exists before the seal that isn't already protected, apart from the first line of a draft with no personal key, shown as its title in the drafts list.
Three cryptographic modes — post-quantum by default, Classic in the chip, Compact with minimal assumptions. Switch anytime without losing contacts.
One person (1:1), several (shared key), only you (personal key), or none yet (a draft). Those are the audiences Sealbox covers.
Animated QR pairing in person, or remote with honest trust-on-first-use; a security code of 13 words per person (26 in all) verifies identity. Routine rotation never raises a false alarm.
Any channel — messenger, email, a post, SMS — or none: screen to camera, by QR, with no network. The channel only carries ciphertext; the read-only extension opens what you receive.
Sealed behind your live biometrics, resistant to After-First-Unlock extraction. Backup optional, end-to-end encrypted, reopened only by the 24-word phrase. Underneath all of it, the device passcode you chose: alphanumeric and high-entropy, it closes the last documented door.
In 1:1, view-once by default: each message's key dies on reading. Rotate at your pace; Delete now erases the old key from this device instantly; deleting a personal key is crypto-shredding. The composer page is ephemeral — what you don't keep doesn't stay — and "Write" on the home screen opens a draft that saves itself, sealed, from the first letter.
No server — observable on the network. A public threat model that names its own limits. The cryptographic core will be published at launch, to read and compile.
We'd rather you understand the tool than buy a promise nobody can keep. This same page ships inside the app.
Standards before invention. Where IETF, NIST, or Apple define a formally analyzed construction, Sealbox adopts it verbatim: HPKE (RFC 9180, native CryptoKit) in three ciphersuites; X-Wing (peer-reviewed IND-CCA proof, IACR CiC 2024); ML-DSA-65 (FIPS 204, formally verified by Apple); Ed25519 (RFC 8032). The honest stack: primitives via Apple CryptoKit + Argon2id via libsodium (the most-audited implementation, backup KDF only) + three auditable own implementations — the Ed25519+ML-DSA-65 composite (IETF draft), the recovery-phrase encoding (over the BIP-39 word list), and a canonical serializer. Zero custom primitives.
Where the choice of hash is ours, it's Keccak. Every hash Sealbox itself decides — deriving the session and vault keys, the identity fingerprint, the security code (13 words per person), the recovery phrase's check digit — is SHA-3, not SHA-2. Not because SHA-2 is known to be broken, but because provenance is part of what you're evaluating: SHA-3 came out of a five-year open competition among 64 entries, designed outside the agency that designed its predecessors. SHA-2 stays only where a standard or a format fixed by Apple names it — inside HPKE (HKDF-SHA-256), in the pre-hash of the composite signature (SHA-512), and in verifying Apple's signed purchase receipt (ES256, hashed with SHA-256, plus a SHA-384 device check) — and removing it from the first two would mean abandoning the analyzed constructions themselves. So the honest claim isn't "no SHA-2 anywhere". It's that where Sealbox chooses the hash, it's Keccak, and SHA-2 appears only where a standard or Apple requires it.
Verify the serverless claim yourself. Sealbox has no backend — so the absence of traffic is observable. Watch the app with iOS privacy reports or a proxy: cryptographic operations make no network requests at all. The app's own network access is Apple's: the App Store (StoreKit) for the one-time purchase and, only if you turn the backup on, iCloud; whatever else travels is the app you chose as transport, carrying ciphertext. This page practices the same discipline: no JavaScript, no fonts fetched, no cookies — open your browser's network inspector right now. The site is served by Cloudflare, which processes the requests it receives.
Don't want to trust even our code? Use the chip. In Classic mode the decryption key lives inside the Secure Enclave and never reaches app memory — the mechanics run in Apple silicon, whose key module Apple submits for FIPS 140 validation, with a bounty in the millions and a decade of the data-extraction industry attacking it. You trust Apple — you already do, you're holding an iPhone — and read the rest: our part around the chip will be published at launch.
What we publish. At launch, the cryptographic core will be published source-available — read it, compile it, verify the encryption yourself, not just take our word. Alongside it, the full design: white paper, this threat model, and the design notes below. What this doesn't prove: that the app on the App Store was compiled from that code. On iOS that correspondence can't be demonstrated — builds aren't reproducible and Apple re-signs the binary. What you can verify from outside is the published core and the absence of a server, observable on the device: cryptographic operations make no network requests. Core + white paper — at launch
Where's the independent audit? There isn't one yet — and the trust model doesn't rest on one. Audit what, is the question. Sealbox contains zero custom primitives: encryption and signatures start from Apple's CryptoKit (its ML-DSA formally verified by Apple itself; the composite signature is our composition of two of them), and libsodium only enters in the Argon2id that derives the backup key — the most-audited implementation of it available. Hardware-key custody anchors in the Secure Enclave: silicon whose key module Apple submits for FIPS 140 validation, and, from A12 onward, no public key extraction to show for it, despite a decade of extraction tools (Cellebrite, NSO) attacking it — a fact of the public record, not proof of inviolability. What remains — our assembly of those parts — is exactly what will be published, at launch, for you to evaluate. It's the secret anchored in Apple's silicon and the code around it open to evaluation — not a vendor's promise. A third-party audit of the published core would be added comfort, not the foundation; the money from the first three price batches is meant to pay for it, and once it is published, the price rises. What you buy today doesn't wait for it.
Writing happens in Sealbox's own composer; the extension only reads. A custom keyboard would need Full Access — seeing everything you type, everywhere — and Sealbox never asks for it.
Reading is free for everyone; writing is one purchase. There is no server, so a recurring fee would be charging rent for nothing — you buy the tool, you own the tool. And no server means no running costs that outlive the sale: what the purchase funds is the tool itself keeping pace with iOS.
A passcode can be shoulder-surfed, brute-forced on old hardware, or compelled quietly. Live biometrics enforced inside the Secure Enclave can't be watched over your shoulder or guessed — but they can be forced with the device in hand, and the threat model says so. The fallback is your recovery phrase — not a weaker lock.
Secure Enclave keys can't migrate to your next iPhone. The default favors safe migration; the advanced option pins to the chip the keys it can hold: with Hardware mode, the Classic KEM, the Quantum operation-signing key and the outer layer of the Quantum KEM; the Compact key and the root identity stay in the Keychain.
The root identity is composite in every mode; the message signature is post-quantum only in Quantum. Forging your identity requires breaking both algorithms, not one.
Forward secrecy that depends on someone remembering to turn it on protects no one. So 1:1 starts in view-once, and epoch — for what must be reread months from now — is an explicit choice by the writer, message by message. The app never switches regimes silently.
Deliberate. PGP brings keyservers, trust ceremonies, and 1990s packet formats. Sealbox is a clean break — simpler to use and to audit.
Price by batch: $59.99 for the first 350 purchases, $79.99 for the next 350, $99.99 for the next 150. Once the independent audit of the core is published, $299.99 — the price only goes up from here.
The app is free: receiving, opening, verifying, pairing — whoever you write to reads you at no cost, with no account (a reply is writing too, so replying takes the purchase). One purchase unlocks writing — and your own wax seal, the initial that marks who sealed a Sealbox (seeing the wax on what you receive is free) — because sealing is the act that defines the tool: it's the only thing that costs. Producing sovereignty is paid; consuming it is free — which is exactly what lets your whole circle read and verify you without anyone else buying anything. No subscription. For the people this is built for — journalists, lawyers, anyone serious about who reads what — the price is measured against a single prevented leak, not against free apps that monetize you. At launch, the cryptographic core will be published for you to read, compile, and verify — the price buys an app whose cryptographic core you don't have to take on faith. Every capability described above is in the app on day one — none of it is sold as "coming soon". The money from the first three batches is meant to pay for the independent audit of that core; once it is published, the price rises.
No form, no list, no tracker — it's just email. If the button doesn't open your mail app, write to support@sealbox.io with the subject "Notify me".
Coming to the App Store · iOS 26+
In transit, yes — and that's worth having. But the channel's protection ends where the content lives: on the device, in app databases, in backups, in every copy along the way. Sealbox seals the text itself, so the channel never holds it in the clear — in transit or at rest. Different layer, different job; they compose.
Reading is free because a sealed text is only worth sending if the other side can open and verify it: your contact downloads Sealbox, pairs, verifies you, and reads — paying nothing, creating no account. Writing is the act that defines the tool, and the one purchase that funds everything — no ads, no data harvesting, no outside sponsor; one honest purchase, once, pays for development. It lands on whoever seals — the person who initiates and, because a reply is sealed too, whoever replies — the side that carries the duty of confidentiality — and for them the price is measured against a single prevented leak. If a leak would genuinely cost you, the price is not the expensive option. The price is set by batch: $59.99 for the first 350 purchases, $79.99 for the next 350, $99.99 for the next 150; once the independent audit is published, $299.99.
In view-once — the 1:1 default — no, and that's the point: that message's key is destroyed when it's opened, so neither you nor anyone holding your phone can reopen it; paste the same block again within 24 hours of reading it and it answers "Message already read". When content needs to be reread later, the writer turns view-once off for that message and it goes out in the epoch regime. The choice belongs to the sender, message by message.
Two layers. Whoever finds the locked phone doesn't get the keys: they release only to your live biometrics — a passcode doesn't open them (an already-unlocked device and forced biometrics are limits of the threat model). And you don't lose your identity, if backup is on: restore on the new device with your 24-word recovery phrase, and your identity, contacts, and recoverable personal keys return. Your contacts see no alarm — your identity is the same. Before you write to each of them again, you confirm their keys: one invite from you, one reply from them (the app tells you when you write to someone still pending). Once that's done, view-once conversations restart with the next message; whatever was sent to you in them and you hadn't read yet needs a resend.
Not yet — and we won't pretend otherwise. But ask what an audit would even cover: Sealbox has zero custom primitives: encryption and signatures start from Apple's CryptoKit (the composite signature is our composition of two of them), and libsodium only enters in the Argon2id that derives the backup key — the most-audited implementation of it available. And hardware-key custody anchors in the Secure Enclave, whose key module Apple submits for FIPS 140 validation; from A12 onward there is no public key extraction — a fact of the public record, not proof of inviolability. What remains, our assembly, will be published at launch, source-available, for you to read and compile. It's the secret in Apple's silicon plus published code, not a vendor's promise. Watch the network, read the core, or use Classic mode, where the decryption key never leaves the chip. The money from the first three price batches is meant to pay for an independent audit of the core; once it is published, the price rises. What you buy today is complete without it.
Yes — iOS 26+ at launch. Going deep on one platform (Secure Enclave, CryptoKit, the share sheet) is what makes the security properties real instead of lowest-common-denominator. Other platforms only happen if they can keep the same guarantees.
Nothing. No account, no analytics, no crash reporters sending content, no telemetry of any kind. There is no Sealbox server to send anything to. This website keeps the same discipline: no cookies, no JavaScript. It is served by Cloudflare, which processes the requests it receives.
Two features in the app for the person with the most to lose: a phone kept apart, and a one-gesture wipe. Neither changes the cryptography, and no guarantee on this page depends on them.
An onboarding profile for a phone you deliberately keep off the network: backup off by default (turning Vault Mode on switches the automatic backup off), "Generate QR" on by default in the composer, and "Read QR" one tap from the home screen; pasting still works. It reduces the perimeter to that one dedicated device — it doesn't make any device immune, and the cryptography underneath doesn't change.
The panic gesture crypto-shreds everything at once. What it doesn't do, said now: it only asks iCloud to delete the backup this device sent — offline, or on a slow network, the backup survives and opens with your phrase, and after "Erase identity" the copy of the previous life stays; and what another device already received doesn't come back. If you never turned the backup on, the gesture doesn't reach iCloud at all. Count on it with the phone unlocked. The retention window is in Settings — off, 7 days or 24 hours: it erases drafts older than the window the first time the app or the extension opens after the deadline, and old keys when the app starts from scratch and before any decryption, always after your biometrics, and view-once conversations unused for longer than the window are ended; the cost is that an epoch message sealed to a key that has already gone no longer opens; turning it on switches the automatic backup off, the manual backup is refused while it is on, and the app warns that backups you exported before keep the keys and drafts of that moment — only you can delete them. The gesture exists for the same person Vault Mode exists for. It doesn't change the cryptography, and no guarantee on this page waits on it.
Sealbox