How it works
A walk through the full chain, from anonymous registration to encrypted delivery, that makes beChat a zero-knowledge, post-quantum messenger.
A beginner-friendly explainer of the cryptographic problem beChat solves: why RSA and ECDH are vulnerable to quantum computers, what ML-KEM-1024 and ML-DSA-87 do, and why "harvest now, decrypt later" is a real threat.
Read the guide →SMS has no end-to-end encryption, transits the SS7 network in plaintext, and ties your identity to a phone number that can be SIM-swapped or recycled. Here is what changes when a messenger leaves SMS behind.
Read the guide →This page walks through every step of how a beChat message gets from your phone to your contact's phone without anyone in between being able to read it. Each step has a one-line "In plain English" summary below it. If the technical paragraph is more than you want, the summary is all you need.
For definitions of every technical term in plain language, see the glossary.
When you install beChat, the app generates a random 8-character PIN locally and pairs it with a device identifier the app creates. No email address, phone number, or legal name is ever requested. Your account is identified to the server by these values, so the server cannot tie your identity to a telecom provider, an email host, or a real-world name.
You get a random 8-character code, like a gym locker number, plus a random ID for your phone. That is your entire identity. The server knows which locker you are, not who you are.
When you start a conversation, beChat runs a hybrid key exchange: a classical X3DHDouble RatchetThe key-ratcheting construction beChat implements for end-to-end encryption, the same mechanism Signal and WhatsApp use. It generates a brand-new key for every message so a single compromised key does not expose past or future messages.Open in the glossary handshake using X25519 (the same mechanism Signal uses) and a post-quantum ML-KEM-1024ML-KEMThe post-quantum key-exchange algorithm beChat uses to let two phones agree on a shared secret that a future quantum computer cannot figure out. Standardized by NIST as FIPS 203.Open in the glossary key encapsulation. The two shared secrets are combined into a single root key using a domain-separated KDF. If either algorithm holds, the session is secure. ML-KEM-1024 is a lattice-basedLattice-based cryptographyA family of post-quantum math problems built on multi-dimensional grids (lattices) of points. They are hard for both normal and quantum computers. ML-KEM and ML-DSA are lattice-based.Open in the glossary mechanism standardized by NISTNISTThe U.S. National Institute of Standards and Technology. It ran the multi-year public competition that chose the post-quantum algorithms beChat uses (FIPS 203 and 204). It also standardized AES and SHA-3.Open in the glossary as FIPS 203. This protects you against "harvest now, decrypt later"Harvest now, decrypt laterAn attack where someone records your encrypted traffic today, while it is still unbreakable, and stores it for years until a future quantum computer can crack it. It is why post-quantum encryption matters now, not later.Open in the glossary attacks where an adversary records ciphertextCiphertextThe scrambled, unreadable version of a message after encryption. It looks like random noise to anyone who does not have the key.Open in the glossary today to break it once quantum hardware matures.
When you start chatting, the two phones agree on a shared secret using two different types of math at the same time: the classic math Signal uses, and a newer post-quantum math that even a future quantum supercomputer can't crack. Both secrets are mixed together, so if either one holds, your session is safe. (Full explainer: What is post-quantum encryption?)
Every device and message key is signed with two signature schemes at once: classical Ed25519ML-DSAThe post-quantum signature algorithm beChat uses to prove who sent a message and that it was not tampered with. Standardized by NIST as FIPS 204.Open in the glossary and post-quantum ML-DSA-87 (FIPS 204). The two schemes mutually bind each other: Ed25519 signs the ML-DSA public key, and ML-DSA signs the Ed25519 key back. A verifier checks both. If a quantum computer could forge Ed25519 signatures in the future, the ML-DSA-87 signature still holds. This is a hybrid signature combiner: both must hold for the key to be trusted.
Every key is signed twice: once with today's signature math, once with post-quantum signature math. Both signatures must be valid. If a future quantum computer learns to forge one type, the other still catches it.
On top of the hybrid handshake, beChat uses a Double RatchetDouble RatchetThe key-ratcheting construction beChat implements for end-to-end encryption, the same mechanism Signal and WhatsApp use. It generates a brand-new key for every message so a single compromised key does not expose past or future messages.Open in the glossary construction, the same key-ratcheting mechanism used by Signal and WhatsApp, implemented from scratch in Rust. Every message uses a fresh key derived from a ratcheting chain, so compromising one message key does not expose past or future messages. This is called forward secrecyForward secrecyA property where every message uses its own fresh key, so a key stolen today cannot unlock messages sent yesterday or tomorrow. The Double Ratchet provides this automatically.Open in the glossary and post-compromise security.
beChat extends the Double Ratchet with continuous post-quantum ratcheting (protocol v7): on every DH ratchet step (when the sending role swaps between participants), the ratchet re-runs ML-KEM-1024ML-KEMThe post-quantum key-exchange algorithm beChat uses to let two phones agree on a shared secret that a future quantum computer cannot figure out. Standardized by NIST as FIPS 203.Open in the glossary and mixes the post-quantum shared secret into the root key alongside the classical X25519 DH output. This means the post-quantum protection does not stop at the initial handshake. It runs throughout the entire session, re-keying with post-quantum secrets every time the ratchet advances. This is the same approach Signal's SPQR (Triple Ratchet) and Apple's PQ3 take, using ML-KEM-1024 rather than ML-KEM-768.
Every single message gets its own fresh lock and key. If someone ever picked the lock on one message, the rest would stay sealed. The old keys destroy themselves after one use. And every time the conversation switches direction, a new post-quantum lock is added on top, so the quantum protection keeps refreshing, not just at the start. This is the same protection Signal and WhatsApp use, with an extra post-quantum layer that keeps running.
Each message is encrypted on your device with a symmetric key derived from the ratchet, using AES-256-GCM-SIVAES-256-GCM-SIVThe encryption beChat uses to scramble message content and attachments. It is a hardened variant of AES-256-GCM, the standard the U.S. government approves for top-secret documents, designed to stay safe even if a nonce is accidentally reused.Open in the glossary, a hardened variant of AES-256-GCM designed to stay safe even if a nonce is accidentally reused. The message header is also encrypted separately with its own derived key, so metadata like the ratchet counter is hidden from the server. The encrypted blob is sent to the beChat server, which stores it and forwards it to your contact. The server only sees ciphertextCiphertextThe scrambled, unreadable version of a message after encryption. It looks like random noise to anyone who does not have the key.Open in the glossary. It never has access to the plaintextPlaintextThe readable, unscrambled version of a message or file. This is what encryption protects. beChat never sends plaintext over the network or stores it on the server.Open in the glossary, the keys, or the ratchet state. This is what makes beChat a zero-knowledgeZero-knowledge (server)A design where the server that runs the service cannot read your data. The beChat server stores your messages only as scrambled blobs and has no key to unscramble them. Like a post office, it can read the address on each envelope (who it is for, when it was sent) but cannot open it.Open in the glossary messaging architecture.
Your phone scrambles the message into noise before it leaves. Even the envelope's metadata is scrambled. The server stores and forwards the noise. It has no way to unscramble it. Only your contact's phone can turn the noise back into text.
For direct messages, beChat uses sealed sender to keep the sender's identity out of the stored message. The sender's identity is encrypted inside the message envelope using X25519 ephemeral Diffie-Hellman and AES-256-GCM-SIV, and the server stores the message without a sender PIN. The recipient's phone decrypts the sender identity locally. The server still authenticates the account that submits the message and issues the delivery token, so sealed sender reduces what stored records reveal but does not hide the sender from the server itself. To prevent abuse, sealed sender uses server-issued delivery tokens: RSA-PSS-signed tokens bound to the recipient, rate-limited to 500 per hour per user, with a 30-day anti-replay window. A sender must present a valid, unconsumed token to send a sealed message.
Alice's name is locked inside the envelope, so the stored message just says "for Bob." The server still sees that Alice's account handed the envelope in, so this is about keeping records lean, not about hiding Alice from the server. To stop spam, Alice needs a one-time ticket (a delivery token) that the server issued to Bob and that only works once.
Attachments (images, files, voice notes) are encrypted with AES-256-GCM-SIVAES-256-GCM-SIVThe encryption beChat uses to scramble message content and attachments. It is a hardened variant of AES-256-GCM, the standard the U.S. government approves for top-secret documents, designed to stay safe even if a nonce is accidentally reused.Open in the glossary on your device before they leave it, with an additional HMAC-SHA256 integrity check. The symmetric key used for the attachment is wrapped with the message ratchet and sent alongside the encrypted message. The server stores only the encrypted file and never sees its contents.
Photos, files, and voice notes are scrambled on your phone before they're uploaded, using the same encryption standard the U.S. government approves for top-secret documents. The server only ever sees the scrambled version.
Group chats use MLSMLS (Messaging Layer Security)An IETF standard (RFC 9420) for end-to-end encrypted group chats. The group shares a tree of keys that changes whenever someone joins or leaves, so people who leave cannot read later messages. beChat uses it with a post-quantum key exchange for all group chats.Open in the glossary (Messaging Layer Security, RFC 9420), the IETF standard for end-to-end encrypted groups, implemented with OpenMLS on the libcrux cryptography backend. beChat uses the hybrid post-quantum ciphersuite MLS_256_XWING_CHACHA20POLY1305_SHA256_Ed25519: key exchange combines ML-KEM-768 with X25519 (X-Wing), so an attacker has to break both, and messages are encrypted with ChaCha20-Poly1305 and signed with Ed25519. MLS organizes the group as a key tree. Every membership change is a commit that moves the group to a new epoch with fresh keys, so a removed member cannot decrypt later messages. New members join through an encrypted Welcome message. Until a group's first commit, its messages are sent pairwise over the members' one-to-one sessions. Group state is stored in the same SQLCipher database as the rest of your history. The server keeps the group's member list so it can deliver messages, but it never holds group keys.
A group shares a set of keys that only its members hold, built so that the group can change all of its locks at once. Whenever someone joins or leaves, it does exactly that, so a person who leaves can't read what is said afterwards. The key exchange mixes post-quantum math with classical math, and each message is signed so members can check who sent it.
Your local message database is protected with SQLCipherSQLCipherAn encrypted version of the database that stores your chat history on your phone. It is locked by your PIN, so without the PIN even someone holding your phone sees only scrambled noise.Open in the glossary, an encrypted SQLite extension. The database key is a random Data Encryption Key (DEK) wrapped under one or more Key Encryption Keys (KEKs). PIN-based KEKs use (memory-hard, 64 MiB) to derive the KEK from your PINPIN (in beChat)A random 8-character code your phone generates when you install beChat. It is your account identity, like a gym locker number. It is not a password you choose, and it says nothing about who you are.Open in the glossary, so your conversation history is encrypted at rest and unreadable without the PIN. On supported devices, KEKs can be hardware-backed (Android StrongBox / TEE, Linux TPM, Windows DPAPI). A 12-word recovery phrase (BIP39, 128-bit entropy) can optionally wrap the DEK so you can restore your history on a new device. Losing both your PIN and your recovery phrase means losing access to your local history. There is no backdoor, on purpose.
Your chat history on your phone is locked behind your PIN, using memory-hard encryption that resists brute-force guessing. On supported devices, the key is backed by hardware security so it can't be extracted even if someone has your phone. You can optionally write down a 12-word recovery phrase so you can restore your history on a new phone. Without your PIN or your recovery phrase, your history is gone forever. There is no back door, on purpose.
All network traffic between your device and the beChat server is protected with TLSTLSThe encryption that protects the connection between your phone and a server, the same technology that puts the padlock in your browser. beChat uses it for every request.Open in the glossary, certificate pinningCertificate pinningA rule where your phone only trusts one specific ID badge for the beChat server. So even if someone fakes a badge that looks officially issued, your phone refuses to talk to them.Open in the glossary (SPKI SHA-256, live and backup pins baked into the app at compile time), and HMAC-SHA256 request signingHMAC request signingA tamper-proof seal on each network request that proves it really came from your account and was not modified on the way. Works alongside TLS for defense in depth.Open in the glossary with a per-request random nonce for replay protection. Certificate pinning prevents man-in-the-middle attacks even if a CA is compromised. Auth tokens use PASETO v3.local, not JWT.
The connection itself is tamper-proof. Your phone checks the server's ID badge and only trusts the one specific beChat badge, so even a convincing fake gets refused. Every request is individually signed and stamped with a one-time code so it can't be replayed. Nobody can quietly slip in between you and the server.
To protect against man-in-the-middle attacks on the initial key exchange, beChat computes a safety number: a SHA-512 hash of both parties' identity public keys, formatted as 12 groups of 5 digits. You compare this number with your contact through a trusted channel (in person, by phone, or by video call). If the numbers match, nobody is intercepting your conversation. If they differ, the key exchange was compromised and you should not trust the session.
After you start a conversation, both phones show a long number. You read it to your contact (in person or by a trusted call) and they check that theirs matches. If the numbers match, nobody is listening in. If they don't, someone is trying to intercept your messages.
Android push notifications are delivered through Google Firebase Cloud Messaging (FCM)Firebase Cloud Messaging (FCM)Google's service for delivering push notifications on Android. For new messages, beChat uses it only to tap your phone and say "wake up, fetch something." That notification contains no message content and no sender, and the message itself never goes through Google.Open in the glossary. A new-message notification contains no message content and no sender. It only tells your device to wake up and fetch the encrypted blob from the beChat server. Contact-request and incoming-call notifications include the other person's PIN and display name so your phone can show who is asking.
When a message arrives, Google's push service just taps your phone on the shoulder and says "wake up, there's something to fetch." The actual message content never goes through Google. It stays on the beChat server as scrambled noise until your phone picks it up.
The beChat server stores what it needs to deliver messages: your PIN, your device identifier, your public keys, your push token, your contact and group relationships, optional profile details you choose to set, and encrypted message blobs. It records routing metadata (recipient, size, timestamps, delivery receipts), and request IP addresses are kept in a 30-day audit log. It stores no plaintext messages, no plaintext attachments, and no analytics data. The server is hosted on an independent European provider in Germany, governed by Belgian law.
The server knows your locker number, who you are connected to, and when envelopes move. It never sees what is inside them. It runs in Europe, on an independent provider rather than a big-tech cloud.
beChat does not include analytics SDKsSDKA "software development kit," a bundle of third-party code an app can include. Many apps include analytics or advertising SDKs that quietly collect your behavior. beChat includes none of those.Open in the glossary, crash reporting SDKs, advertising libraries, or any third-party data-collection code. It does not phone home to big tech. It does not upload your address book, track your location, or record your browsing behavior. Android push notifications go through Google Firebase Cloud Messaging, viewing a shared location loads map tiles from OpenStreetMap, and link previews are fetched by your device from the linked site. It does not require a Google account to function (only to install the beta build via Google Play).
The app skips analytics, ads, crash reporters, and third-party data-collection code entirely. It does not quietly report home to anyone. It does not upload your address book, track your location, or watch your browsing. The only reason you need a Google account at all is to install the beta from the Play Store.
Read the detailed security model, browse the feature list, check the FAQ, or look up any term in the glossary. Ready to try it? Join the beta.