Last updated: September 2, 2026. This page describes what cryptography this app uses, what it uses it for, and what it does not do. It exists because we answer questions about encryption to Apple, to Google, and under US export regulations, and those answers should be checkable against something rather than taken on faith.
Publishing this costs us nothing in security. A cryptographic system should remain secure when everything about it except the private keys is public — that principle is older than the field itself, and a design that depends on secrecy of its own description was already broken. If anything here looks wrong to you, we would rather hear about it.
We use standard, published algorithms and we do not invent cryptography. Every primitive below is a public specification with a long history of analysis.
| Algorithm | Specification | What we use it for |
|---|---|---|
| X25519 | RFC 7748 | Key agreement between two devices |
| Ed25519 | RFC 8032 | Signatures proving a message came from a given identity |
| ChaCha20-Poly1305 | RFC 8439 | Encrypting message contents, with authentication |
| HKDF-SHA256 | RFC 5869 | Deriving separate keys from one shared secret, so no key is used for two purposes |
| SHA-256 | FIPS 180-4 | Hashing, and deriving the rotating addresses described below |
ChaCha20-Poly1305 rather than AES is a deliberate choice. It is designed to run in constant time in software without special hardware, which matters on the range of phones this app has to work on.
Two different things get called “the encryption”, and the distinction is worth being clear about.
The mathematics is entirely standard. We wrote none of it and we would not. Home-made cryptography is the most reliable way to build something that looks secure and is not.
The arrangement is ours. How a message is framed, which bytes are authenticated alongside the ciphertext and in what order, how a delivery address is derived from keys and the current time, and how a device decides whether to send over Bluetooth, Wi-Fi, a local network or the internet — all of that we designed. No standards body has reviewed it, because it is specific to this app.
Ours is not the same as secret. It is written down in full, and we are glad to share the detail with anyone who wants to examine it — see the contact address at the end.
Message text is encrypted on the sending device and decrypted on the receiving device. Our server never holds a key of any kind and cannot read anything passing through it. When two phones are close enough to reach each other directly over Bluetooth or Wi-Fi, no server is involved at all.
Messages waiting on the server are not filed under a name, a phone number or an account. They sit under a token derived from cryptographic keys and the current time period, which changes regularly. The server cannot tell you who owns one, and two tokens belonging to the same person in different time periods do not look related.
The sender's identity is inside the encrypted portion, not attached to the outside. The server learns that something arrived for some address. It does not learn who sent it.
Pairing in the current beta does not perform a key agreement, and you should know that before trusting it with anything sensitive.
When two people pair today, the shared secret protecting their conversation is derived from their two public identity keys. It is not the output of a fresh X25519 exchange. The practical consequence: anyone who observed both pairing codes could derive the same secret and read messages between those two people.
The real handshake — a three-message exchange producing an ephemeral secret that nothing public reveals, signed under both identity keys — is implemented in the protocol core but is not yet connected to a radio. Until it is, the app shows the weaker state rather than claiming the stronger one, and this page says so too.
Also not yet built: relaying messages through other people's phones, and pairing by NFC. NFC peer-to-peer does not exist between modern iPhones and Android phones, so it is not planned.
Because this app carries its own implementations of the algorithms above rather than calling only
the operating system's, it is classified under the US Export Administration Regulations as
ECCN 5D002 — encryption software. We answer Apple's and Google's encryption questions
accordingly, including the declaration ITSAppUsesNonExemptEncryption, which we set to
true because that is what is true.
The functionality is ordinary confidentiality for personal communication. It is not special-purpose, not designed for any government or military use, and uses only published algorithms.
If you are a security researcher, an app reviewer, or simply someone who wants more detail than this page gives, we will provide the full protocol specification on request. If you believe you have found a flaw, we want to hear it before anyone else does.
Contact: de57@me.com