Security: what we guarantee and what we can’t

This page is generated from the same file our test suite checks. A claim appears here only if its tests pass.

What we guarantee

• No phone number, email address or name is needed to use Dead Safe. Your account is a 12-word recovery phrase created on your device.Proven by: identity derives the same keys from the same phrase, and different keys from different phrases
• Our servers never receive your identity key, your name or your contact list. Even the first message that connects two people is sealed, so its contents don't reveal who sent it. (The server still sees the IP address a message comes from; see the limits.)Proven by: what the relay can see the hello reveals neither identity nor the reply queue · what the relay can see messages contain no plaintext, no ratchet keys and no identities
• Messages are end-to-end encrypted with the Double Ratchet algorithm (the design used by Signal). The classical building blocks (X25519, Ed25519, XChaCha20-Poly1305, SHA-256, Argon2id) come from open-source libraries that have had independent security audits. How Dead Safe combines them is our own protocol code, which has not been audited yet.Proven by: handshake and messaging exchanges a long conversation in both directions · handshake and messaging a third party with their own session to Bob cannot read Alice’s messages
• Post-quantum protection throughout the conversation: every conversation starts with hybrid key agreement (X25519 plus ML-KEM-768, the NIST standard), and every time the conversation changes direction the keys are refreshed with a new X25519 exchange and a new ML-KEM-768 exchange together. To read recorded traffic, an attacker would have to break both X25519 and ML-KEM-768; ML-KEM-768 is designed to withstand quantum computers, as NIST's standard sets out.Proven by: handshake and messaging post-quantum: the ML-KEM-768 secret is part of the session key · post-quantum ratchet every reply mixes in a fresh ML-KEM-768 secret, with new keys each step · post-quantum ratchet knowing every X25519 key is not enough: the wrong ML-KEM key cannot decrypt · post-quantum ratchet refuses a chain that arrives without its ML-KEM ciphertext (no silent downgrade) · post-quantum ratchet full sessions: replies carry ML-KEM ciphertexts that the relay never sees
• Forward secrecy: someone who steals your device's current keys still cannot decrypt messages your device has already received. (As in every Double Ratchet app, keys for messages that arrived out of order are kept until those messages arrive.)Proven by: handshake and messaging forward secrecy: a later copy of the session cannot decrypt earlier messages · handshake and messaging forward secrecy boundary: keys for messages still on their way are kept until they arrive
• Altered or replayed messages are rejected.Proven by: handshake and messaging rejects a tampered message and leaves the session usable · handshake and messaging rejects a replayed message
• Invitations are signed by the identity they contain, so changing where a conversation is delivered breaks the invitation. A signature can't prove who sent you an invitation; comparing safety numbers does, and the app marks every contact as not verified until you do.Proven by: invitations rejects an invitation whose relay, queue or prekey was altered · invitations a whole substitute invitation from someone else is valid, but the safety number exposes it
• You can compare a safety number with each contact to confirm no one is intercepting your conversation.Proven by: identity gives both people the same safety number, and a different one for a different pair · invitations a whole substitute invitation from someone else is valid, but the safety number exposes it
• Each conversation uses its own private delivery queues. Only you can read your queue, and once two people are connected, only your contact can post to it.Proven by: relay access control nobody but the owner can read a queue · relay access control once secured, only the contact can post (no injection, no spam) · relay access control a signature for one queue cannot be used on another · relay access control rejects replayed and stale requests
• Messages are padded in 256-byte steps, so the server sees only a rough size, never the exact length.Proven by: what the relay can see pads messages so short and medium texts are the same size · what the relay can see padding hides exact length within 256-byte steps; only the step is visible
• The server records message arrival only to the nearest minute, deletes each message as soon as your app confirms it has it, and deletes uncollected messages after 14 days.Proven by: two people messaging through the relay the relay stores minute-level timestamps only · two people messaging through the relay delivers messages both ways and deletes them on acknowledgement · two people messaging through the relay messages nobody collects are deleted after 14 days
• Dead Safe never accepts card numbers. Pro can be paid for with cash by post. Your device claims the licence by signing with a key that never leaves it, and it doesn't even ask until the cash has arrived.Proven by: escrow (the old free-Pro holes are closed) the fake-card and free-coupon prototype endpoints are gone · escrow (the old free-Pro holes are closed) cash flow: order, confirm, claim by device signature, verifiable licence · Pro via cash by post the claim secret never leaves the device: only a public key, status checks and a signature are sent

What we cannot protect you from (yet)

• The relay sees your IP address. Like any server you connect to, the relay sees the network address you connect from, unless you use Tor or a trusted VPN.Plan: Built-in Tor routing in the mobile apps.
• Timing can link your conversations. Your app checks all your queues from the same connection, so the relay could guess that those queues belong to one person. It still cannot see who is at the other end of each queue.Plan: Tor, plus spreading queues across independently run relays.
• A hacked phone or computer defeats any messenger. If spyware is running on your device, it can read your screen and keyboard. No messaging app can prevent that. Keep your device updated and locked.Plan: Not solvable by an app. We will never claim otherwise.
• The web version trusts the server for its code. A web app is downloaded from the server each time you open it, so a compromised server could send altered code. Signed mobile apps with reproducible builds close this gap.Plan: Native iOS and Android apps with reproducible builds; the web version stays as a convenience.
• Keys refresh when the conversation changes direction. New X25519 and ML-KEM-768 keys are mixed in each time the other person replies. A long run of messages in one direction stays on one chain whose keys move forward with every message but get no fresh randomness until a reply arrives. Signal's and SimpleX's ratchets work the same way. Post-quantum key material adds about 2.3 KB to each message, inside the encryption.Plan: None needed for security; we may compress the post-quantum data later, as Signal's SPQR does.
• Our post-quantum library has not had an independent audit. ML-KEM-768 comes from @noble/post-quantum, which tests against the official NIST vectors but has not yet had one. Because the design is hybrid, a flaw in it alone cannot expose your messages: the X25519 layer still has to be broken.Plan: Switch to an audited implementation as soon as one is available for the web.
• No independent audit of Dead Safe yet. The cryptographic libraries we use have been audited. Our protocol and app have not yet had an independent audit. Every security claim is backed by an automated test you can run yourself.Plan: A published third-party audit before the 1.0 release.
• An invitation proves nothing about who sent it until you compare safety numbers. An invitation works once. If someone intercepts it before your contact uses it, they could connect in their place; if someone replaces the link with their own, you would connect to them. The app marks every contact as not verified until you compare safety numbers, which reveals both. An attacker who learns an invitation can also fill its queue with junk to stop the connection.Plan: Share invitations in person by QR code where possible. Planned: a one-time posting token inside each invitation, and an option to block messaging until safety numbers are compared.
• No notifications while locked (web version). While Dead Safe is locked, even the app cannot open your queues, so it cannot tell you when a message arrives.Plan: Content-free wake-up notifications in the mobile apps.
• Auto-destroy only runs when the app is opened. An app cannot run while it is closed. Someone who copies your device's storage first can bypass auto-destroy, but still faces the encryption and your passphrase.Plan: Hardware-backed keys in the mobile apps.
• Your passphrase is the lock on your device. Stored data is encrypted with a key made from your passphrase using Argon2id. The app requires at least 10 characters but cannot stop you choosing a guessable phrase, and anyone who copies your device's storage can try guesses offline. Four or more random words are much safer.Plan: Planned: a built-in strong-passphrase generator and a common-password block list. Hardware-backed key storage in the mobile apps.
• The second-profile feature is public knowledge. Dead Safe is open source, so anyone can know the feature exists. What they cannot tell, without your passphrase, is whether you use it.Plan: None needed; this is the honest limit of deniability.
• The second profile is hidden in one copy of your storage, not across several. Someone who examines a single copy of your device's storage can't tell whether a second profile exists. Someone who has an older copy as well, for example from a backup, can see that the second slot changed, which suggests it is in use.Plan: Researching storage designs that hide which parts change, for the mobile apps.
• Our server could link a Pro licence to its cash order. Order codes contain no identity, but the server issues each licence for a specific order.Plan: Blind signatures (RFC 9474) so even we cannot link them.

The cryptography

• Message encryption: XChaCha20-Poly1305 with 256-bit keys.
• Key agreement: X25519 combined with ML-KEM-768 (NIST FIPS 203) when a conversation starts; then a hybrid Double Ratchet that runs a new X25519 and a new ML-KEM-768 exchange on every reply (the design SimpleX uses).
• Signatures: Ed25519.
• Key derivation: HKDF-SHA-256 and HMAC-SHA-256; Argon2id for your passphrase.
• Libraries: @noble/curves, @noble/hashes, @noble/ciphers and @scure/bip39, which have had independent security audits, and @noble/post-quantum, which has not yet had one.

Check it yourself

The source code (published before launch) includes the tests behind every claim. Run npm run check to type-check the code, run the unit tests, drive two simulated users through the app in a real browser, and verify that every claim on this page is backed by a passing test.

Report a problem

If you find a security issue, or a claim that our code doesn't support, please report it through the security policy in our repository (published before launch).