Public exchange
The server only forwards public keys.
Private A and Private B never leave the phones.
burnit.chat
ephemeral encrypted channel
Back to chat
● How it works
An encrypted tunnel.
Only between you.
Two browsers create a shared confidential channel that exists only during the conversation. Encrypted data is forwarded by the server, but only your browsers have the keys required to read it.
Simply put
No logins. No email. No accounts.
We do not verify identities or create profiles. The link connects exactly two people, and the conversation lives only in the memory of their open browser tabs. Once the channel is burned, there is no archive to return to.
- login
- email address
- phone number
- account history
01
Key exchange
Private keys never leave the devices.
01 / PUBLIC HANDSHAKE
the forwarding server handles public data only
Creator
Private A stays here
SERVER
forwarding only
forwards · never decrypts
Guest
Private B stays here
A
PUBLIC A
→
server
→
B
A
←
server
←
PUBLIC B
B
02 / locally
ECDH + HKDF
Private A × Public B
02 / locally
ECDH + HKDF
Private B × Public A
A
03 / ENCRYPTED TUNNEL
Key A→B · AES-256-GCM · Key B→A
the server sees encrypted data only
B
The same secret
Each side calculates it locally.
End-to-end tunnel
AES-256-GCM · a separate key in each direction
The server has no AES keys and cannot read the conversation.
-
1
Creator's key pair
The creator generates an ephemeral ECDH pair. The room ID is a 128-bit digest of the creator's public key.
-
2
Short invitation
The invitation contains only a short room ID. The creator's full public key is temporarily held in server memory.
-
3
Public exchange
When the guest joins, the server forwards both public keys. Private keys never leave the browsers.
-
4
Key verification
The guest checks that the creator's key digest matches the ID in the link. Both sides then derive the AES keys.
-
5
Opening the tunnel
An encrypted key confirmation opens the channel. From then on, the server sees encrypted data only.
02
Room lifecycle
The room exists only for the lifetime of the connection.
Waiting
The invitation waits for up to 15 minutes and accepts only the first guest. The creator has 2 minutes to return after a brief disconnect, while the guest page retries automatically every 3 seconds.
Conversation
Messages exist in the memory of two open tabs. The server stores no history, and after a brief connection loss both sides have 2 minutes to return.
Disconnect
A brief network loss gives both sides 2 minutes to return. Explicitly ending the chat invalidates the room immediately.
Burn
The room record is removed from MySQL, the other socket is closed, and keys and messages are removed from the view.
03
What the server sees
- room ID and status
- public keys
- timing and size of encrypted frames
04
What it cannot see
- message contents
- private keys or AES keys
- conversation history
05
Using your phone during a chat
While a room is active, the page asks the system to keep the screen awake. When you switch to another app, the system releases that lock. If the WebSocket is interrupted, the waiting creator has 2 minutes to return. A guest who opens the invitation during that time does not need to refresh the page — the connection retries automatically every 3 seconds. During a chat, both creator and guest have 2 minutes to return to the app. Messages are paused during that time, while explicitly ending the chat still burns the room immediately.
Anyone who obtains it before first use can take the guest slot. For a high-risk conversation, compare the security code through another channel.