Frozen Chat
Security

Plain-language security.

Frozen Chat is built on the assumption that our own servers could be compromised. This page explains, without marketing, what that design protects and where its limits are.

Not yet independently audited.The protocol is a public draft. An external audit is planned before we call it done.

What the server can see

  • That your account exists, and its licence tier

    Needed to deliver messages and apply limits.

  • Your username

    Looked up as a keyed hash (HMAC). A copy is kept encrypted for account administration.

  • Your public keys and your signed device list

    So others can start encrypted chats with you.

  • Encrypted envelopes waiting for a device

    Deleted when delivered, or after 30 days at most.

  • Envelope sizes (padded) and times (rounded to the minute)

    Unavoidable for a delivery service; padding blurs sizes.

  • Your IP address while you are connected

    Used in memory for rate limits; never written to the database or logs.

  • Which devices follow which (opaque) group id

    To wake devices for new group messages. No group names, no roles, no sender.

  • Encrypted attachments, by random name and padded size

    Deleted from storage after 30 days.

What it can't see

  • Message text, photos, videos, files, voice messages or stickers you send
  • Call audio and video (relays forward encrypted packets they can't open)
  • Who sent a sealed-sender message
  • Group names, photos, descriptions, member roles or who posted in a group
  • Your contacts, your address book or a phone number (there is none)
  • Your private keys, your Recovery Key or your recovery PIN
  • Push notification content (pushes carry no content, only “wake up”)

Messages: the Signal protocol, with post-quantum keys

One-to-one chats use libsignal, the same open 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. While you are connected it can still see your IP address and timing, so sealed sender reduces what is recorded rather than making you invisible.

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

  • Not yet independently audited. The protocol specification is a public draft and may still change.
  • First contact is trust-on-first-use until key transparency is added. Comparing safety numbers closes this gap.
  • Metadata while connected. Someone who controls the live server can see IP addresses and the timing of connections, even if nothing is stored.
  • 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.

Check our work

The full protocol specification, the threat model and every line of client and server code are public in the source repository (see docs/protocol and docs/security/threat-model.md). Found a problem? Please tell us privately first via the contact page.