Encrypted chat with no account: how Btwinus puts AES-256 in a link

Open Signal, the gold standard of encrypted messaging, and the first thing it asks for is your phone number. Open Telegram and you'll do the same — and unless you specifically open a "secret chat," your messages sit on Telegram's servers in a form they can read. WhatsApp encrypts messages end-to-end but ties your identity to a phone, syncs metadata to Meta, and stores undelivered messages on its servers.

None of this is fraud — these tools are vastly safer than plain SMS — but the encryption story has limits. It protects content in transit. It doesn't make you anonymous, it doesn't make the conversation ephemeral, and it depends on you trusting a company.

Btwinus tries to answer a narrower question: can you have a one-off encrypted conversation with someone, with no account on either side, no server in the middle, and nothing left over after you close the tab? The answer turns out to be yes, and the mechanism is interesting.

What "no account" actually requires

For a chat to genuinely require no account, three things have to be true:

1. No identity binding. No phone number, no email, no username — because every one of those is a database row somewhere.
2. No server retention. If a server stores messages "until delivered," that's a database too. Even ephemerally.
3. Direct transport. Messages have to travel from one browser to the other without a relay that can read them.

Most "no signup needed" chat tools fail at #2 or #3. They use a server to relay messages, and even if they delete after delivery, the server can read everything in transit.

The Btwinus model: encryption in the URL

Here's the move: instead of using a server to introduce two browsers, the introduction goes through the link itself. The link contains the encrypted information needed to start a peer-to-peer connection. The recipient's browser decrypts it, replies, and the two browsers connect directly without ever talking to a server.

Step by step:

1. Alice clicks "Start a new chat". Her browser generates a fresh AES-256 key, derived from a randomly generated passphrase using PBKDF2 with 100,000 iterations. The browser also creates a WebRTC offer — the cryptographic handshake material needed to establish a peer-to-peer connection.
2. The offer is encrypted with the AES key, base64-encoded, and embedded in a URL fragment (the part after #). URL fragments never get sent to a server, even by the browser. So the encrypted offer travels purely client-side.
3. Alice sends the link via WhatsApp, email, anything. She sends the passphrase via a different channel — a phone call, SMS, in person.
4. Bob opens the link. His browser sees the encrypted blob in the fragment, asks him for the passphrase, derives the same key, and decrypts the offer.
5. Bob's browser generates a WebRTC answer, encrypts it with the same key, and produces a reply link he sends back to Alice.
6. Alice pastes Bob's reply link. Her browser decrypts the answer, hands it to WebRTC, and the two browsers complete the handshake.
7. From this point forward, the two browsers talk directly via a WebRTC DataChannel, encrypted with DTLS 1.3. No server is involved in any message.

The whole arrangement requires zero server-side state. The "introduction" is the link, the "authentication" is the passphrase, the "transport" is WebRTC's built-in DTLS. The only network calls are direct browser-to-browser.

Why two channels (link + passphrase)

The most important security property here isn't AES-256 — that's commodity. It's the two-channel split.

If you sent the encrypted link and the passphrase through the same channel (say, both via WhatsApp), an attacker who compromises that channel gets both halves and can decrypt everything. The whole encryption story collapses.

Sending them separately means an attacker has to compromise two different channels — your WhatsApp and your phone line, your email and the in-person verbal exchange. That's much harder. It also means you can use a not-very-secure channel for the link (the link is encrypted, so it's safe to share publicly) as long as the passphrase travels somewhere narrower.

This pattern has a name in cryptography: it's a kind of "out-of-band" or "secondary channel" verification, similar to how Signal's Safety Numbers work, except more lightweight.

The pieces, named

Component	What it does
AES-256-GCM	Symmetric encryption of the WebRTC offer/answer. Used in classified-information systems by US and other governments. Approved for TOP SECRET data.
PBKDF2 (100k iterations)	Stretches the human-readable passphrase ("storm-fox-river-4821") into a 256-bit key. The 100k iterations make brute force expensive even for short passphrases.
WebRTC DataChannel	The peer-to-peer transport. Browser-native, no library needed. Once established, messages don't touch any server.
DTLS 1.3	The transport encryption WebRTC uses by default. Modern, fast, with perfect forward secrecy — even if a key is compromised later, past traffic stays unreadable.
Short Authentication String	A short hash of the session keys shown to both users, so they can verbally compare and confirm there's no man-in-the-middle.

What this approach is good at, and what it isn't

Good at: one-off conversations with someone you don't share an account-relationship with — a journalist receiving an anonymous tip from a source, a lawyer with a new client, a privileged moment that shouldn't exist anywhere afterward. Sending a single secret like a password. Avoiding any company knowing the conversation happened.

Not good at: daily messaging with friends. Async messages (both browsers must be online to talk). Group chats. File transfer beyond small payloads. Anything that needs to persist after you close the tab.

This is a deliberate scope. Tools that try to be both private and always-available drift toward needing servers and accounts. Btwinus chose the opposite — accept the limits of "both online, ephemeral, one conversation at a time" in exchange for the strongest possible privacy properties.

The mental model, finally

An encrypted chat doesn't actually need a chat app. It needs:

• A way for two browsers to find each other (the link)
• A shared secret only they know (the passphrase)
• A direct transport (WebRTC)

Once you accept that the "introduction" can travel through any channel a human controls — WhatsApp for the link, phone call for the passphrase — the entire server infrastructure most chat apps depend on becomes unnecessary. The link and the passphrase together are the introduction.

That's why Btwinus is one HTML page. There's nothing to host, nothing to log into, nothing to leak.