Chat Without an Account: How NoChat's Anonymous Join and Post-Quantum Crypto Work

Two features define NoChat's privacy promise: you can join a conversation without creating an account, and your direct messages are protected by post-quantum cryptography today. This post explains how both work and why they matter.

Joining Without an Account

Most messaging apps have a signup wall. You click an invite link, and instead of joining the conversation, you're redirected to a registration form that asks for your email, a password, and (usually) a phone number. By the time you actually reach the chat, you've handed over real-world identity data.

NoChat works differently. When you click an invite link, you see three options:

1. Join as Guest — one click, start chatting immediately. No account created.
2. Create account — email signup if you want persistent identity.
3. Sign in — for existing users.

The "Join as Guest" path creates an anonymous session on the fly: your client generates a temporary identity key pair locally, the server issues a session token tied to that ephemeral key, and you're dropped directly into the conversation. The server never learns your email, phone number, or any real-world identity. It sees an opaque device key and a session token.

This is the same flow that NoChat has used for anonymous signup since launch. We extended it to the invite landing page so that the signup wall is completely gone for invited users.

What does the server actually store for a guest?

For a guest session, the server stores:

• A UUID (randomly generated)
• The user's public identity key (generated on device)
• An encrypted session token

There's no email. No phone. No name. If you never upgrade to a named account, the only thing linking your messages to "you" is your device's private key — which lives exclusively on your device.

If you want to continue using your guest account across devices or after clearing your browser, you can upgrade to a named account (email + password). Your message history, contacts, and keys are preserved.

Post-Quantum Encryption for Direct Messages

The second piece of NoChat's privacy story is post-quantum cryptography for 1:1 DMs.

Why post-quantum matters now

Today's public-key cryptography (RSA, ECDH with P-256 or X25519) is secure against classical computers. But quantum computers running Shor's algorithm can break these schemes efficiently. A sufficiently large quantum computer would retroactively decrypt all encrypted traffic captured today.

This is the harvest now, decrypt later threat: adversaries record encrypted traffic today and store it, betting that quantum computers will become available within the next 10-15 years. If your DMs are end-to-end encrypted with classical crypto only, anything you send today could be decrypted in 2035 or 2040.

What NoChat ships today

For direct messages (1:1 conversations), NoChat uses a hybrid key exchange:

session_key = HKDF(
  X25519(sender_static, recipient_ephemeral) ||
  ML-KEM-1024.Decapsulate(encapsulation, recipient_kem_private_key),
  salt, info, 32
)

In plain terms: we combine a classical X25519 key exchange with an ML-KEM-1024 key encapsulation. The resulting session key is only breakable if an attacker can break both the classical exchange AND the post-quantum encapsulation. Breaking either alone doesn't reveal the session key.

ML-KEM (also called Kyber-1024) is the NIST-standardized post-quantum key encapsulation mechanism, finalized in FIPS 203. It's lattice-based and believed to be secure against quantum adversaries. We use the cloudflare/circl implementation in Go on the server, and equivalent WASM on the client.

The session key is then used with AES-256-GCM for symmetric encryption — a cipher already considered quantum-resistant at 256-bit key length.

Honest scope

Post-quantum protection applies to direct messages only right now. Group messages use classical E2EE (X25519 + AES-256-GCM). The full double-ratchet (per-message forward secrecy) is on the roadmap. We're not claiming to be fully quantum-proof — we're claiming that 1:1 DMs sent through NoChat today are protected against the harvest-now-decrypt-later threat.

This is the same scope Signal takes with their PQXDH deployment.

What the server sees

With both features combined:

The server routes encrypted blobs between devices. It cannot read the content of messages, calls, or files regardless of legal demands, because it never has the keys.

What's next

• Double ratchet (per-message forward secrecy): Code exists, not yet activated fleet-wide. This will extend PQ protection to include forward secrecy per message, not just per session.
• Post-quantum for groups: ML-KEM for group key distribution.
• Sealed sender: Hides which user is sending a message from the server. Code prepared, not integrated.

These are roadmap items, not shipped features. We update the crypto inventory as each ships.

---

NoChat is open source (MIT). You can read every line of the encryption code. If you find a vulnerability, report it to security@nochat.io.