Poof documentation

A chatroom that forgets.

Poof is a private chatroom that lives in a browser tab. No account, no phone number, no email. You open a room, share it, talk. When the timer runs out, the room is gone. Poof.

These docs explain what Poof is, why it exists, how it works, what it protects you from, what it does not, and how you can check every claim yourself.

Poof at a glance

Read at your own depth

1. Understand. What Poof is and why. Philosophy, How a room works, Super Rooms & tokens.
2. Explore. Why quantum computers matter to a chat app. The quantum problem, Harvest now, decrypt later, Post-quantum & hybrid keys, Quantum Lab.
3. Verify. How it is protected, and how to check. Security architecture, Data lifecycle, Threat model, Verify it yourself.
4. Build. The protocol, step by step. Developer guide.

About & philosophy

Less data, by design.

Privacy is not only about hiding information. It is also about reducing how much information exists in the first place.

Storage is cheap, so most of the internet keeps everything, just in case. Every message, contact list and login stays on someone's server for years. Each of those copies is something that has to be protected, forever.

MORE DATA ──▶ MORE STORAGE ──▶ MORE METADATA ──▶ MORE ATTACK SURFACE ──▶ MORE TO PROTECT, FOREVER

Poof starts from the opposite default. A conversation exists for as long as people are having it, and not much longer.

LESS DATA ──▶ LESS RETENTION ──▶ SMALLER ATTACK SURFACE ──▶ LESS LONG-TERM EXPOSURE

Privacy is not the same as security

Poof is built around confidentiality and ephemerality. It helps with privacy because it never asks who you are. It is not an anonymity tool on its own: the network still sees which IP addresses connect, and when.

Create, use, expire, poof Concept

Grass grows, exists for a season, then returns to the soil. Nothing about it is meant to last forever, and that is not a flaw. Poof treats a conversation the same way.

NATURE                      POOF
──────                      ────
seed            ──▶         create room
grow            ──▶         people join
exist           ──▶         messages are used
change          ──▶         timer runs down
return          ──▶         room state disappears · poof

An analogy, not a security proof. What actually expires, and where, is described in Data lifecycle.

Why “Poof”?

Because that is what the room does at the end.

How it works

The life of a room.

From the moment you press “Create a room” to the moment it disappears.

  YOU                          POOF SERVER                       GUEST
   │                                │                              │
   │  1  create room ──────────────▶│  room id + expiry, in memory │
   │  2  your browser makes the     │                              │
   │     room key (never sent)      │                              │
   │  3  share: link · QR · 4 words ─────────────────────────────▶ │
   │◀──── 4  signaling relay: "how to reach each other" ─────────▶│
   │                                │   (no keys, no messages)     │
   │◀═══════════ 5  direct encrypted channel (WebRTC) ═══════════▶│
   │◀═══════════ 6  post-quantum upgrade (ML-KEM-768) ═══════════▶│
   │◀═══════════ 7  talk: every message encrypted in-browser ════▶│
   │                                │                              │
   │                8  timer ends ─▶ room state expires ─▶ poof

1–2 · Creating a room

Your browser asks Poof's server for a new room. The server records two things in memory only, with an expiry equal to the room lifetime: that the room exists and when it ends. Meanwhile your browser generates a random 256-bit room key with the Web Crypto API. The key goes into the part of the link after the #, the fragment. Browsers never send the fragment to servers, so Poof's server never receives it.

3 · Sharing it

4–6 · Connecting

To find each other, the browsers exchange connection details through Poof's server (“signaling”). The server passes them along without storing them. Once a direct WebRTC data channel is open, the browsers run a post-quantum key exchange directly between themselves and combine the result with the room key. From then on, messages are protected by both. If a direct path is impossible, traffic goes through a relay that forwards encrypted data without being able to read it.

You can follow it in the room: waiting → connected → sealed. Messages are only sent once the room is sealed.

7 · Talking

Each message is encrypted in your browser with AES-GCM-256 and a fresh random 96-bit IV, then sent over the data channel. Poof's servers are not on the message path.

8 · Poof

When someone leaves, the conversation is wiped from the other person's screen immediately and their input is disabled. When the timer ends, the server's record of the room expires on its own, and opening the link again only shows that the room no longer exists. There is nothing to recover.

What the server knows

Rooms

When ten minutes isn't enough.

Every room has the same privacy architecture. A Super Room just gives the conversation more room to breathe.

How a group stays private

In a Super Room every message is still encrypted in the sender's browser and opened only in the other participants' browsers, with the same hybrid post-quantum protection as a Classic Room. No server ever holds a group key or sees content. The room's size limit is enforced, so nobody can squeeze in once it's full.

Files

Files travel over their own encrypted channel, cut into small pieces that are each locked before they leave your browser. Poof never sees a file's name, type or contents. Direct connections allow larger files than connections that need the relay.

Why tokens, not accounts

Poof doesn't need to know who you are to give you more. Instead of signing up and paying from a profile, you burn a Poof token when you create a Super Room.

Tokens use blind signatures. After you pay, your browser “blinds” a token and Poof signs it without seeing it (RSA blind signature). Your browser then unblinds it. When you spend it, Poof can check its own signature, but it has never seen that token before, so it cannot link the payment to the room or to you. Each token works exactly once.

TOKENS ──▶ BURN ──▶ SUPER ROOM ──▶ TIMER ENDS ──▶ POOF
   │                     │
   └── no account,       └── same encryption,
       no profile            same nothing-kept

Prices for the 1-hour and 24-hour options are shown when you create a Super Room.

Quantum, part 1

What happens to today's secrets when tomorrow's computers arrive?

Encryption is a bet that some maths problems are too hard to solve. Quantum computers change which problems are hard. This page explains how, without the hype.

Bits and qubits

A normal bit is 0 or 1. A qubit can be in a combination of both, called superposition, until you measure it, and then it becomes a plain 0 or 1. Quantum algorithms use quantum gates to arrange those combinations so that wrong answers cancel out and right answers become likely when you measure. That is not “trying every answer at once”. It only helps for problems with special structure. Try it in the Quantum Lab.

Two kinds of encryption, two kinds of risk

Public-key cryptography (RSA, elliptic curves, ECDH key exchange, digital signatures) lets two strangers agree on a secret. It relies on problems like factoring large numbers or computing discrete logarithms. Symmetric cryptography (AES) encrypts the actual data once both sides share a key. It relies on the key simply being too big to guess.

          CLASSICAL COMPUTER                       QUANTUM COMPUTER
                  │                                        │
         ┌────────▼────────┐                     ┌─────────▼─────────┐
         │  RSA · ECC      │                     │  Shor's algorithm  │
         │  factoring /    │                     │  factoring and     │
         │  discrete logs  │                     │  discrete logs     │
         └────────┬────────┘                     └─────────┬─────────┘
                  ▼                                        ▼
        impractical to solve                 solvable, on a large enough
                                             error-corrected machine

A picture of the idea, not a description of how Shor's algorithm works inside. Concept

So the weak spot is the handshake

The data itself (AES-256) holds up well. The vulnerable moment is when two parties agree on a key with RSA or elliptic curves. If someone can later recover that key exchange, they can unlock everything it protected.

Quantum, part 2

Harvest now, decrypt later.

You do not need a quantum computer today to attack today's messages. You only need to record them and wait.

TODAY                                         SOMEDAY
─────                                         ───────
encrypted traffic                             quantum capability
      │                                              │
      ▼                                              ▼
┌──────────────┐   store   ┌──────────────┐   ┌──────────────────┐
│   attacker   │ ────────▶ │  encrypted   │──▶│ try to recover   │
│ records it   │           │   archive    │   │ the key exchange │
└──────────────┘           └──────────────┘   └──────────────────┘

Anyone who can watch a network (an internet provider, a compromised router, a state agency) can save encrypted traffic cheaply and keep it for years. If that traffic relied only on RSA or elliptic-curve key exchange, a future quantum computer could unlock it. For conversations that must stay private for a long time, the risk starts the day they are recorded.

How Poof answers it

  MINIMIZE WHAT EXISTS          nothing stored on servers, rooms expire
+ HYBRID POST-QUANTUM KEYS      classical key + ML-KEM-768
+ FRESH KEYS PER ROOM           each room gets new keys, then they're gone
+ KEYS STAY IN THE BROWSER      the server never holds them
──────────────────────────
= LESS LONG-TERM EXPOSURE

Ephemerality alone is not enough. Poof deleting things does not stop someone else from recording traffic on the network. That is why the encryption itself holds up against future quantum attacks, which is the job of the hybrid post-quantum key. See it play out in the Quantum Lab.

What this does not solve

• A compromised device. If your phone or browser is infected, messages can be read before they are encrypted.
• The link. The classical half of the key travels in the room link. Someone who captured the link and broke the post-quantum exchange could read the room. Both are needed.
• Metadata. A recorder still sees that two IP addresses talked, when, and for how long.

Quantum, part 3

Two locks on every room.

Post-quantum cryptography is ordinary software that runs on today's devices, built on maths problems believed to be hard even for quantum computers.

The NIST standards

In 2024 the U.S. National Institute of Standards and Technology published the first post-quantum standards:

Poof uses ML-KEM-768 for its key exchange.

What a KEM does Concept

A key encapsulation mechanism works like a lockbox. Your guest publishes an open padlock (public key). You put a random secret in a box, snap the padlock shut and send it (ciphertext). Only your guest has the key that opens it. Now you both share the same secret, and anyone who watched only saw a locked box.

ML-KEM-768 in numbers

The keys are bigger, but for a chat handshake a couple of kilobytes, once per room, makes no noticeable difference.

Why hybrid

Post-quantum algorithms are newer than RSA or elliptic curves. A hybrid design does not bet everything on one of them: it combines a classical secret with a post-quantum one, so an attacker has to break both.

  ROOM KEY (classical)                    ML-KEM-768 SHARED SECRET
  256-bit, made in your browser,          agreed directly between browsers
  carried in the link after #             over the encrypted data channel
            │                                         │
            └──────────────┐          ┌───────────────┘
                           ▼          ▼
                     ┌────────────────────┐
                     │    HKDF-SHA-256    │  one fixed, labelled derivation
                     └─────────┬──────────┘
                               ▼
                 HYBRID SESSION KEY · AES-GCM-256
                 used for every message in the room

The room key is the HKDF salt, the ML-KEM shared secret is the input key material, and a fixed, versioned Poof context string keeps the derivation separate from anything else. Before switching, both browsers prove they hold the same post-quantum secret with an HMAC-SHA-256, each side using its own label, so a confirmation can't simply be bounced back. Only then does the room use the hybrid key. A tampered handshake fails this check and the room refuses to upgrade.

Implementation notes

• In the browser. Browsers don't ship ML-KEM natively yet, so Poof uses the browser's built-in ML-KEM-768 where it exists, and otherwise a pinned open-source implementation shipped with the app itself, never fetched from a third-party server at runtime. AES-GCM, HKDF and HMAC come from the browser's own Web Crypto API.
• Side channels. Secret-dependent operations run in constant-time implementations.
• Signatures. Poof does not use post-quantum signatures. Room integrity comes from the shared keys and key confirmation, not from long-term identities.

Quantum Lab Concept

Play with the ideas.

Three small experiments that make the quantum chapters tangible. They are teaching models, not simulations of real hardware or of Poof's code.

1 · A qubit, measured

Before measurement the qubit holds both possibilities. Each measurement gives a plain 0 or 1, and the pattern of results reveals the probabilities.

2 · Two locks

The session key comes from both secrets. Knowing one of them is not enough.

3 · Harvest now, decrypt later

You choose the year. Nobody can reliably predict it, which is exactly why protection has to be in place before it.

Security

Every lock, and what it rests on.

For each protection: the threat it answers, the mechanism, what has to be true for it to work, and where it stops.

┌─────────────────────── YOUR BROWSER ───────────────────────┐
│  room key (Web Crypto)  ─┐                                  │
│                          ├─▶ HKDF ─▶ session key ─▶ AES-GCM │──┐
│  ML-KEM-768 secret  ─────┘                                  │  │ ciphertext only
└─────────────────────────────────────────────────────────────┘  │
        │ signaling (no keys, no content)                         ▼
┌───────▼────────┐                                   ┌────────────────────┐
│  POOF SERVER   │  room id + expiry, in memory      │ WebRTC data channel│
│  no message    │                                   │ direct, or via a   │
│  storage       │                                   │ TURN relay         │
└────────────────┘                                   └────────────────────┘

Where does data go?

Everything Poof touches, and when it's gone.

CREATE ──▶ PROCESS ──▶ TRANSMIT ──▶ USE ──▶ EXPIRE ──▶ DELETE ──▶ POOF

Threat model

Who can learn what.

A security promise is only useful if it says who it protects you from, and who it doesn't.

Attacker by attacker

The web-app problem

Any website can be changed by whoever runs the server. In theory, a compromised server could send you code that leaks your key. Poof's answer is to make the running code checkable: open source, reproducible builds and signed attestations, so a change can't go unnoticed. See Verify it yourself.

Transparency

Don't trust the docs. Check the code.

Every claim on these pages points to something you can inspect.

Check the build

Poof's build is reproducible: the same source always produces the same files, byte for byte. Every release publishes the checksums of what's served, signed by the build system, so you can check that usepoof.chat is running exactly the published code.

1  download the signed checksums from the latest release
2  verify the signature with GitHub's CLI:  gh attestation verify
3  hash the files your browser loaded and compare

Try one right now

You can check the first claim without trusting Poof. It is how every browser works:

1. Open any link with a #something at the end.
2. Open DevTools (F12) → Network and reload.
3. Look at the request URL. Everything after # is missing. It never left your browser.

Security reports

Found something? Tell us first.

If you believe you've found a security issue in Poof, we want to hear about it, privately, before anyone else does.

How to report

• Email security@usepoof.chat with a description, steps to reproduce and the impact you expect.
• Please don't test against other people's rooms, and don't publish details until we've had time to fix it.
• Include your PGP key if you'd like an encrypted reply.
• We acknowledge every report within 48 hours, assess severity, agree a fix plan and coordinate the disclosure date with you. We credit reporters publicly if they wish.

Severity

Safe harbour

We won't take legal action against good-faith research that avoids privacy violations, data destruction and service disruption, accesses no more than needed to show the issue, and gives us reasonable time to fix it before disclosure.

Out of scope

Attacks that need a compromised device or browser, social engineering, denial of service through volume, and issues in third-party services outside Poof's control.

For developers

The protocol, step by step.

How a Poof client talks to the server and to other clients. Read it next to the source.

Building blocks

Handshake

CLIENT A (creator)                                   CLIENT B (guest)
──────────────────                                   ────────────────
key K = random 256 bits (fragment)                   reads K from fragment
        ── SDP offer / ICE via signaling ──────────────▶
        ◀──────────────── SDP answer / ICE ────────────
        ════════ data channel open (DTLS) ════════
(pk, sk) = ML-KEM.KeyGen()
  1 ── public key pk ─────────────────────────────────▶
                                                      (ct, ss) = ML-KEM.Encaps(pk)
                                                      cB = HMAC(ss, label_B)
  2 ◀──────────────────────── ciphertext ct + proof cB ──
ss = ML-KEM.Decaps(sk, ct)
check cB
  3 ── proof cA = HMAC(ss, label_A) ──────────────────▶  check cA
S = HKDF-SHA-256(salt = K, ikm = ss, info = poof context)   (both sides)
every message: AES-GCM(S, random 96-bit IV, plaintext)

If a confirmation fails, the upgrade is rejected and the room reports it instead of switching keys silently.

Message envelope

base64( IV (12 bytes) ‖ AES-GCM ciphertext + 16-byte tag )

files: each chunk = IV (12 bytes) ‖ ciphertext + tag

Example Concept

// Illustrative only: shows the order of operations, not the production API.
const K   = crypto.getRandomValues(new Uint8Array(32));        // room key
const kem = mlKem768KeyGen();                                   // post-quantum keypair
// ... exchange pk / ct over the data channel ...
const S   = await hkdf(K, sharedSecret, POOF_CONTEXT);        // session key
const msg = await aesGcmEncrypt(S, randomNonce(), "hello");

Running it locally

Clone the public repository (linked in the site footer) and follow its README: it lists the requirements and the two commands to start Poof on your machine. Open two browser windows on the local address and create a room between them; you'll see the handshake above happen in your browser's developer console.

Reference

Glossary.

Every term in three steps: plain words, the technical version, and why it matters to Poof.

Qubit

simpleA bit that can be 0, 1, or a mix of both until measured.

technicalThe basic unit of quantum information, described by complex amplitudes; measurement yields a classical bit.

for poofLarge numbers of reliable qubits are what would threaten today's key exchanges.

Superposition

simpleBeing in a combination of states at once.

technicalA qubit state is a linear combination of basis states.

for poofIt's why quantum algorithms can do things classical ones can't, for some problems.

Entanglement

simpleQubits whose results are linked, however far apart.

technicalA joint state that can't be written as separate per-qubit states.

for poofA resource quantum algorithms rely on.

Quantum gate

simpleAn operation that changes qubits.

technicalA unitary transformation applied to one or more qubits.

for poofAlgorithms like Shor's are sequences of gates.

Physical vs logical qubit

simpleRaw hardware qubits vs error-corrected ones built from many of them.

technicalError correction encodes one logical qubit across many noisy physical qubits.

for poofBreaking RSA needs many logical qubits, which is why it isn't possible yet.

Quantum error correction

simpleFixing quantum errors without looking at the data.

technicalCodes that detect and correct errors on encoded qubits.

for poofThe main engineering hurdle between today's machines and dangerous ones.

Quantum advantage

simpleA quantum computer beating classical ones at some task.

technicalDemonstrations exist for specific, mostly artificial problems.

for poofNot the same as breaking encryption. Headlines often mix them up.

Shor's algorithm

simpleA quantum recipe for factoring and discrete logarithms.

technicalPolynomial-time algorithm for integer factorization and discrete log.

for poofBreaks RSA and elliptic-curve key exchange on a big enough machine.

Grover's algorithm

simpleA quantum speed-up for searching.

technicalQuadratic speedup for unstructured search.

for poofWeakens symmetric keys; AES-256 stays strong.

Post-quantum cryptography

simpleEncryption designed to resist quantum attacks, running on normal computers.

technicalSchemes based on problems like lattices or hash functions.

for poofPoof's handshake uses it (ML-KEM-768).

Quantum-safe

simpleExpected to hold up against quantum computers.

technicalInformal term; depends on assumptions and correct implementation.

for poofWe say “designed to resist”, never “unbreakable”.

Harvest now, decrypt later

simpleRecord encrypted data today, unlock it later.

technicalStore-and-wait attack against long-lived ciphertext.

for poofThe reason post-quantum matters before quantum computers exist.

KEM

simpleA way to agree on a shared secret using a public key.

technicalKey encapsulation mechanism: encapsulate / decapsulate.

for poofHow Poof's browsers agree on the post-quantum half of the key.

Lattice cryptography

simpleMaths based on hard problems in multi-dimensional grids.

technicalSecurity from problems like Module-LWE.

for poofThe foundation of ML-KEM and ML-DSA.

ML-KEM

simpleThe NIST-standard post-quantum key exchange.

technicalFIPS 203, module-lattice KEM; ML-KEM-768 is NIST category 3.

for poofPoof uses ML-KEM-768.

ML-DSA

simpleThe NIST-standard lattice signature scheme.

technicalFIPS 204.

for poofNot used by Poof.

SLH-DSA

simpleA signature scheme built only on hash functions.

technicalFIPS 205, stateless hash-based signatures.

for poofNot used by Poof.

Forward secrecy

simpleOld conversations stay safe even if a key leaks later.

technicalSession keys are ephemeral and not derivable from long-term keys.

for poofEach Poof room uses fresh keys that disappear with the room.

URL fragment

simpleThe part of a link after #.

technicalNot sent to the server in HTTP requests.

for poofWhere Poof keeps the classical room key.

WebRTC

simpleBrowser technology for direct connections.

technicalPeer-to-peer media and data channels with DTLS encryption.

for poofHow messages travel between browsers without Poof's servers.

TURN relay

simpleA fallback server that forwards traffic when a direct link fails.

technicalRelays packets; sees only encrypted payloads.

for poofLets rooms work behind strict networks.

HKDF

simpleA recipe for mixing secrets into a key.

technicalHMAC-based key derivation function (RFC 5869).

for poofCombines the classical and post-quantum secrets.

AES-GCM

simpleFast, standard encryption that also detects tampering.

technicalAuthenticated encryption with associated data.

for poofEncrypts every message in a room.

Reference

Questions.

29 short answers. Most link to a page with the full story.