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 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, dictation blocked by default, what you type doesn't leak before it's sealed.
Pick the contact and seal. Your keys release only to your Face 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, one tap opens the app's composer with the recipient 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 — 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), 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 the difference from a notes app: in Apple Notes, for one, a note gets its own lock only if you open it and lock it, one at a time — and some notes can't be locked at all. 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 authenticated, recipient-bound: your contact knows it came from you and was meant for them. A durable 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 when durable; in view-once, ~10k for the message that opens the session and for the ones sent before the contact first replies — up to eight 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 durable).
HPKE with Curve25519 + ChaCha20-Poly1305 + Ed25519 — the modern stack trusted by WireGuard and age. Compact payload, minimal assumptions (over SMS, use durable).
Exchange keys face-to-face with an animated QR (the invite is ~14.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.
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 and every share 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". 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.
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 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 message of a new conversation can be the first one opened — there is no inaugural message that has to arrive first. Out of order, you can skip up to 8 messages; past that the app does not open it and tells you how many earlier ones are still unopened — open them, and it opens. And a skipped message keeps opening for 24 hours after a later one was opened; before you open any of them, there is no deadline at all.
Durable stays, by choice. When the recipient needs to reread months from now, turn view-once off for that message: it goes out in the durable 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 durable 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 durable 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 (up to 8 per round, for 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 — nothing of them goes into the backup. 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 as durable.
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 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 — 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. If iCloud is unavailable, the app tells you and offers manual export — it never fails silently. Automatic iCloud backup will be switched on and verified on a real device with the Apple developer account, before launch.
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, 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 durable 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. 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 — Settings › Face ID & Passcode › Change Passcode › Passcode Options › Custom Alphanumeric Code.
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 a guarantee outright: 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. Durable 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 already in the app and haven't yet been verified on a real device.
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.
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 — 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 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 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 13-word security code, 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 where a standard names it — inside HPKE, and in the pre-hash of the composite signature — and removing it from there would mean abandoning the analyzed constructions themselves. So the honest claim isn't "no SHA-2 anywhere". It's that SHA-2 only ever runs inside an audited standard, over a secret that is already Keccak.
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 JavaScript, 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 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. 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, only enters in the Argon2id that derives the backup key — primitives don't get more reviewed than this. Key custody anchors in the Secure Enclave: silicon whose key module Apple submits for FIPS 140 validation with every major OS release, and, from A12 onward, no public key extraction to show for it, despite the best-funded attackers on earth. What remains — our assembly of those parts — is exactly what will be published, at launch, for you to evaluate. It's the trust pattern the hardware-wallet world normalized for custodying fortunes: the secret anchored in 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.
Forward secrecy that depends on someone remembering to turn it on protects no one. So 1:1 starts in view-once, and durable — 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.
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 will be published for you to read, compile, and verify — the price buys a product 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". Before launch, the whole app will go through the final on-device check with the Apple developer account, which is what switches on automatic iCloud backup; Vault Mode and the panic gesture, which haven't had even their first check yet, are marked further down the page. 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.
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 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 durable regime. The choice belongs to the sender, message by message.
Two layers. Whoever finds the phone gets nothing: keys release only to your live biometrics — a passcode doesn't open them. 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. View-once conversations restart on their own with the next message; whatever was sent to you in them and you hadn't read yet needs a resend.
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 only enters in the Argon2id that derives the backup key — the most-audited implementations in existence. And key custody anchors in the Secure Enclave, whose key module Apple submits for FIPS 140 validation with every major OS release, and with no public key extraction from A12 onward. What remains, our assembly, will be published at launch, source-available, for you to read and compile. That's the trust pattern hardware wallets normalized: the secret in silicon plus published code, not vendor promises. Watch the network, read the core, or use Classic mode, where the decryption 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 JavaScript, no external requests.
Sealbox hasn't launched yet, and everything above is what ships on day one. Vault Mode and the panic gesture are already in the app, but haven't yet been verified on a real device — until they are, no guarantee on this page depends on them, so we say that plainly instead of dressing it up.
An onboarding profile for a phone you deliberately keep off the network: backup off by default, QR as the primary way in and out. 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, which crypto-shreds everything at once, is already in the app. What it doesn't do, said now: it only asks iCloud to delete the backup — offline, or on a slow network, the backup survives and opens with your phrase; and what another device already received doesn't come back. Whether it works with the phone locked is for the on-device check to say; until then, count on it unlocked. The retention window leaves this list until it's rebuilt and verified on a real device. The gesture exists for the same person Vault Mode exists for. It doesn't change the cryptography, and none of today's guarantees wait on it.
Sealbox