Sealbox

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.

Free for the first 2 months after launch: get the unlock during this window and the full app is yours for good. After that, US$ 19.99, a one-time purchase, no subscription. Downloading the app is free; what guarantees the full app is getting the unlock, inside the app. Without it you can read and verify, but not write. It isn't a free tier with the real features held back: with the unlock, it's the complete app. And free doesn't mean you're the product: Sealbox has no server (see "Verify the serverless claim yourself" in the security model), no account, no telemetry.

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 its key being used and it answers "Key already used". An exception, also the sender's: if they allowed copying (blocked is the default), you can save the text to a draft with the copy button at the top of the reading screen — the message still can't be reopened, but the draft stays on the device, encrypted, like any other. 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. Restore once and your contacts see no alarm — your identity is the same. The exception is restoring the same backup a second time: the keys the chip generates on the second restore aren't the first one's, and a contact who already knows the first ones refuses the second's invite. 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.

No — 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. 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 trust model doesn't rest on an audit: a third-party audit of the published core would be added comfort, not the foundation.

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 data to. This website keeps the same discipline: no cookies, no JavaScript. It is served by Cloudflare, which processes the requests it receives.