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 an 8-character PIN locally and pairs it with a hardware-based device fingerprint. No email address, phone number, or legal name is ever requested. Your account is identified to the server only by these two 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 fingerprint of your phone. That is your entire identity. The server knows which locker you are, not who you are.
When you start a conversation, beChat performs a post-quantum key exchange. It uses ML-KEM-1024 ML-KEM The 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. Click for full glossary →, a lattice-based Lattice-based cryptography A 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. Click for full glossary → key encapsulation mechanism standardized by NIST NIST The 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. Click for full glossary →, to establish a shared secret that even a future quantum computer Quantum computer A different kind of computer that uses quantum physics to solve certain specific math problems extremely fast. It works on different principles than your laptop, not just faster hardware. Click for full glossary → cannot break. Device and message keys are signed with ML-DSA-87 ML-DSA The 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. Click for full glossary →, a post-quantum signature scheme. This protects you against "harvest now, decrypt later" Harvest now, decrypt later An 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. Click for full glossary → attacks where an adversary records ciphertext Ciphertext The scrambled, unreadable version of a message after encryption. It looks like random noise to anyone who does not have the key. Click for full glossary → today to break it once quantum hardware matures.
When you start chatting, the two phones secretly agree on a shared password using math so hard that not even a future quantum supercomputer could figure it out. They also each sign their identity so nobody can pretend to be you. This is the step that protects your messages decades from now. (Full explainer: What is post-quantum encryption?)
On top of the post-quantum handshake, beChat uses a Double Ratchet Double Ratchet The 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. Click for full 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 secrecy Forward secrecy A 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. Click for full glossary → and post-compromise security.
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. This is the same protection Signal and WhatsApp use.
Each message is encrypted on your device with a symmetric key derived from the ratchet. The encrypted blob is sent to the beChat server, which stores it and forwards it to your contact. The server only sees ciphertext Ciphertext The scrambled, unreadable version of a message after encryption. It looks like random noise to anyone who does not have the key. Click for full glossary →. It never has access to the plaintext Plaintext The 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. Click for full glossary →, the keys, or the ratchet state. This is what makes beChat a zero-knowledge Zero-knowledge (server) A design where the server that runs the service cannot read your data. The beChat server stores only scrambled blobs. It has no key to unscramble them. Think of it as a post office that moves sealed envelopes but cannot open them. Click for full glossary → messaging architecture.
Your phone scrambles the message into noise before it leaves. 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.
Attachments (images, files, voice notes) are encrypted with AES-256-GCM-SIV AES-256-GCM-SIV The 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. Click for full glossary → on your device before they leave it. AES-256-GCM-SIV is a hardened variant of AES-256-GCM, the encryption standard the U.S. government approves for top-secret documents, designed to stay safe even if an encryption nonce is accidentally reused. 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.
Your local message database is protected with SQLCipher SQLCipher An 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. Click for full glossary →, an encrypted SQLite extension. The database key is derived from your PIN PIN (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. Click for full glossary →, so your conversation history is encrypted at rest and unreadable without the PIN. Losing your PIN means losing access to your local history. There is no recovery path, on purpose.
Your chat history on your phone is itself locked behind your PIN. Without the PIN, even someone holding your phone sees only scrambled noise. If you forget your PIN, 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 TLS TLS The 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. Click for full glossary →, certificate pinning Certificate pinning A 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. Click for full glossary →, and HMAC request signing HMAC request signing A 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. Click for full glossary →. Certificate pinning prevents man-in-the-middle attacks even if a CA is compromised, and HMAC signing protects request integrity and authenticity.
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. Nobody can quietly slip in between you and the server.
Android push notifications are delivered through Google Firebase Cloud Messaging (FCM) Firebase Cloud Messaging (FCM) Google's service for delivering push notifications on Android. beChat uses it only to tap your phone and say "wake up, fetch something." The notification contains no message content, and the message itself never goes through Google. Click for full glossary →. This is the only component of beChat that transits Google infrastructure. The notification payload is encrypted and contains no message content. It only tells your device to wake up and fetch the encrypted blob from the beChat server.
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 the minimum required to operate the service: your PIN, your device fingerprint, your public keys, and encrypted message blobs. It stores no plaintext messages, no plaintext attachments, no contact lists in plaintext, and no analytics data. The server is hosted on an independent European provider.
The server holds the absolute minimum to keep running: your locker number, your phone's fingerprint, your public keys, and sealed envelopes. It runs in Europe, on an independent provider rather than a big-tech cloud.
beChat does not include analytics SDKs SDK A "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. Click for full glossary →, crash reporting SDKs, advertising libraries, or any third-party data-collection code. It does not phone home to big tech. It does not collect your contacts, your location, or your browsing behavior. The only external service it uses is Google Firebase Cloud Messaging for Android push notifications, and those payloads are encrypted and contain no message content. 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 read your contacts, your location, or 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.