In messages, email, or posts, you compose a Sealbox in a protected space, before it touches any messaging app: a sealed object that travels any channel as ciphertext. 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, no dictation, nothing leaks before it's sealed.
Pick the contact. Face ID. You've generated a Sealbox — encrypted and signed.
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. Reply in place — the key is already set.
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. 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: it disappears on its own in ~30 days, or, before that, you hit Delete now and lock the past instantly.
Messages and drafts: it all sits sealed behind your live biometrics. On a lost phone, even one already unlocked once (AFU), there's nothing to extract.
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 — there's nothing to extract. 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 what makes them safer than any notes app: even the well-known ones don't protect content this way by default; the rare few that come close are the exception. 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 per-mode signing keys, and one composite root identity that certifies the rest — generated automatically when you start. Every message is encrypted and signed (encrypt-then-sign, recipient-bound): your contact knows it came from you and was meant for them.
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; 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 (fits SMS, short posts).
HPKE with Curve25519 + ChaCha20-Poly1305 + Ed25519 — the modern stack trusted by WireGuard and age. Compact payload, minimal assumptions.
Exchange keys face-to-face with an animated QR (the key bundle is ~8.7 KB — 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.
Trust on first use, with verification. A remote contact works immediately, visibly marked "unverified". You compare a 13-word security code — derived from both parties' root identities — 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.
You write in Sealbox's own composer: the plaintext is born there — no third-party keyboard (which would need Full Access), dictation blocked, predictions and keyboard learning 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.
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.
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 BIP-39 recovery phrase (24 words, 256 bits) is the single secret that reopens it on a new device; there is deliberately no human password, because a guessable password would reopen the offline brute-force door that the phrase closes. 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, there's nothing to manage — generate once and move on.
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, long-lived keys are perfectly valid; rotating for its own sake buys nothing. What locks the past is deleting the old key (forward secrecy for that epoch). By default it lives ~30 days — the window for contacts to reach you through your next messages — and disappears on its own. But the timing is yours: Delete now erases it 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. The ~30 days are a ceiling (not even an attacker can postpone the deletion — that's what guarantees per-epoch FS), never a wait imposed on you.
Sealbox doesn't promise per-message forward secrecy — that needs a continuous server-backed session; here forward secrecy is per-epoch, when the old key is deleted.
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. Recovery when biometrics fail permanently: restore from backup with your phrase.
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.
Text is born in Sealbox's own composer — no third-party keyboard, dictation stopped, predictions off. Nothing exists before the seal that isn't already protected.
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). Every audience a text can have, covered.
Animated QR pairing in person, or remote with honest trust-on-first-use; 13 words verify identity. Routine rotation never raises a false alarm.
Any channel — messenger, email, a post, SMS. 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.
Rotate at your pace; Delete now locks the past instantly; deleting a personal key is crypto-shredding. The composer is ephemeral by default — what you don't keep doesn't stay.
No server — observable on the network. A public threat model that names its own limits. The cryptographic core 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), BIP-39, and a canonical serializer. Zero custom primitives.
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 only traffic is whatever app you chose as transport, carrying ciphertext. This page practices the same: no scripts, no fonts fetched, no analytics, no cookies — open your browser's network inspector right now.
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 secure key store carries FIPS 140-2/3 and Common Criteria certifications, 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 is published.
What we publish. At launch the cryptographic core is 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. Core + white paper — at launch
Where's the independent audit? There isn't one — and the trust model doesn't rest on one. Audit what, is the question. Sealbox contains zero custom primitives: encryption and signatures are Apple's CryptoKit (its ML-DSA formally verified by Apple itself) and libsodium, the most-audited cryptography library in existence — primitives don't get more reviewed than this. Key custody anchors in the Secure Enclave: silicon carrying FIPS 140-2/3 and Common Criteria certifications, and a decade of the best-funded attackers on earth with no public key extraction to show for it. What remains — our assembly of those parts — is exactly what's published for you to evaluate. It's the trust pattern the hardware-wallet world normalized for custodying fortunes: the secret anchored in certified silicon, 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; if one is ever published, the list 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. 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 keys to the chip for those who want exactly that.
Authenticity gets the same post-quantum treatment as confidentiality. Forging your identity requires breaking both algorithms, not one.
Deliberate. PGP brings keyservers, trust ceremonies, and 1990s packet formats. Sealbox is a clean break — simpler to use and to audit.
Founding price $299.99 for the first two weeks at launch — 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. One purchase unlocks writing, 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 is published for you to read, compile, and verify — the price buys a product you don't have to take on faith. Everything this page describes is in the app on day one — nothing here is "coming soon". The list price rises only if an independent audit of that core is ever published; buying before it means owning the audited product of the same purchase.
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 · 2026 · 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 investors to satisfy; one honest price, once, funds maintenance for years. It lands on the person who initiates — 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, $449.99 is not the expensive option.
Two layers. Whoever finds the phone gets nothing: keys release only to your live biometrics — a passcode doesn't open them. And you lose nothing, 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.
No — and we won't pretend otherwise, nor sell you the promise of one. But ask what an audit would even cover: Sealbox has zero custom primitives — encryption and signatures are Apple's CryptoKit and libsodium, the most-audited implementations in existence — and key custody anchors in the Secure Enclave, certified (FIPS 140-2/3, Common Criteria) and publicly attacked for a decade without a key extracted. What remains, our assembly, is published for you to read and compile. That's the trust pattern hardware wallets normalized: certified silicon plus open code, not vendor promises. Watch the network, read the core, or use Classic mode, where the key never leaves the chip. If an independent audit of the core is ever published, the list 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 server to send anything to. This website keeps the same discipline: no cookies, no scripts, no external requests.