Plain-language security.

Messages: the Signal protocol, with post-quantum keys

One-to-one chats use libsignal, the same library the Signal app uses, without changes. A chat starts with PQXDH: a key agreement that combines classic elliptic-curve keys with a post-quantum key (ML-KEM, also called Kyber). Someone who records your traffic today and gets a quantum computer later still can't read it. After that, the Double Ratchet gives every message a new key, so one stolen key doesn't unlock the past (forward secrecy) and the conversation heals after a compromise.

Your keys are made on your phone and stay there, stored in an encrypted database whose key is protected by the phone's secure hardware where available. Frozen Chat invents no cryptography of its own: it combines published protocols and well-reviewed libraries.

Sealed sender

Normally a server has to know who is sending a message. With sealed sender, your app puts the sender's identity inside the encrypted envelope and proves it is allowed to deliver with a token derived from the recipient's profile key. The server delivers the envelope without being told who it is from.

Nothing logged

We don't collect your phone number, e-mail address or contacts: the system has no place to put them. The servers keep no access logs and no IP addresses, and this website runs no analytics, trackers or third-party scripts. Stored timestamps are rounded to the minute or the day.

Groups: MLS

Groups use Messaging Layer Security (MLS, RFC 9420), the IETF standard for group encryption, with a hybrid X25519 + ML-KEM-768 cipher suite for post-quantum protection. The server acts only as a delivery service: it orders encrypted group messages but is never a member, never holds group keys and can't add a device to a group, because every app checks each member against that person's signed device list. When someone is removed, the group moves to new keys.

Files, voice messages and one-time media

Attachments are encrypted on your phone with a fresh key per file, padded to hide their exact size, and uploaded under a random name. The key travels only inside the encrypted message. Storage deletes files after 30 days.

Calls

Call setup is sent as ordinary end-to-end encrypted messages. The media is encrypted with DTLS-SRTP, and both apps check the other side's fingerprint against what arrived over the encrypted chat, so a relay in the middle can't listen in. Relays (TURN) only forward packets, with short-lived credentials that don't carry your account.

No phone number, no e-mail

You sign up with a username and a small proof-of-work puzzle that slows down spam bots. There is no phone number or e-mail field anywhere in the system. The server looks usernames up by keyed hash. Your contacts are never uploaded.

When you create an account you get a Recovery Key. It is shown once, only on your device. Together with an optional recovery PIN it is the only way back into your account if you lose every device: we can't reset it for you, because we don't have it.

Notifications

Push notifications through Google or Apple contain no message, no sender and no chat: just “wake up”. The app then fetches and decrypts on the device. Google or Apple still learn that your phone received something, and when. On phones without Google services, UnifiedPush or the app's own connection are used instead.

Verifying contacts

Each conversation has a safety number you can compare in person or by scanning a QR code. If a contact's keys change, the app warns you. Until key transparency arrives, the very first contact with someone is trust-on-first-use: verify safety numbers for people who matter.

Known limits

• First contact is trust-on-first-use until key transparency is added. Comparing safety numbers closes this gap.
• Timing while connected. Someone who took over the live server could watch when devices connect, even though nothing is logged.
• The web app is lower assurance than the phone app: a browser runs the code the server sends. It is served with a strict content security policy and holds no account identity key, but it can't be fully protected from its own server.
• Group membership. The server knows which devices follow which opaque group id (not the group's name or roles), so it could infer that certain devices share a group.
• A compromised, unlocked phone can read what that phone can read. App lock and disappearing messages limit the damage; nothing can fully prevent it.
• The website support chat is not end-to-end encrypted. For private support, message @frozenchat in the app.

Responsible disclosure

Found a vulnerability in the apps, Frozen Chat Web, the server, the website or the shop? Please tell us privately first.

• E-mail [email protected] with “Security report” in the subject. Include what you found, the affected version or URL, steps to reproduce and the impact you expect.
• We confirm receipt within 3 working days and keep you updated until it is fixed.
• Please give us 90 days (or until a fix ships, if sooner) before going public. We will agree a date with you.
• We will credit you in the release notes if you like.
• Good-faith research within these rules is welcome and we won't take legal action against it. Please only test against your own accounts, don't access or change other people's data, don't degrade the service for others (no denial-of-service or spam), and don't use social engineering or physical attacks.