enkripsiyon

What protects a message

• WebCrypto primitives

  X25519, Ed25519, AES-256-GCM and HKDF-SHA-256, all from the browser’s WebCrypto, with an ECDH P-256 / ECDSA fallback where the modern curves are missing. No cryptography was hand-rolled.

• One secret

  The invite key is the only thing a user holds. The room code, the room key and the server’s membership verifier are all HKDF outputs of it; the room key never leaves the browser, and the verifier cannot be worked back into it.

• Forward secrecy per sender

  Each member runs a hash ratchet and message keys are zeroised after use, so a key captured today does not open yesterday.

• Signed messages

  Every envelope carries an Ed25519 signature from the sender’s device key, so one member cannot forge a message from another — which a plain shared-key room allows.

• Roster attestation

  Clients cross-sign their view of the member list and compare hashes, so a server showing different rosters to different people surfaces as a loud bad state instead of a decorative “valid ✓”.

• Chunk-authenticated files

  Files up to 100 MB are encrypted as 1 MiB chunks, and each chunk binds its own index and the total count into the AEAD associated data, so truncating or reordering a file is detected.

Optional, and off until asked for

• A cover passcode

  Switching away or going idle can hide the screen behind a six-character passcode instead of destroying keys and making you retype thirty. The screen itself says a cover is weaker than a lock.

• A duress passcode

  A second passcode opens a decoy conversation you write yourself and erases saved history on the device. The stored record looks identical whether one is set or not.

• A backlog

  Off by default: a member who joins at message 400 cannot read messages 1–399, and no copy exists that would let them. The owner can switch on a backlog and grant reading to the members they choose.

What the server sees

The relay stores and forwards ciphertext. That work is not invisible to it.

What it does not solve

• Backdoored JavaScript

  A hostile server can serve a modified client that steals keys, and nothing in the protocol would notice. Subresource integrity, a strict content security policy and the published BUNDLE-HASHES.txt manifest raise the cost and let anyone who checks detect tampering. They do not make it impossible.

• Traffic analysis

  Message sizes and timing leak the shape of a conversation; there is no padding, no cover traffic, no mixing. The relay sees IP addresses and connection times. This is not an anonymous tool.

• No recovery

  Lose the invite key and the room is gone: no reset link, no support address, no escrow, no backup of your key anywhere. There is no operator override, because an operator override is a backdoor.

How a room starts

1. Create a room with a username. The app shows the invite key once — thirty characters, six groups of five — and offers the owner a recovery file to download.

   K7M2Q-XR4TB-9WNAE-5HJ3P-YZ0FC-D8VG6

2. Send the key to your people over a channel you already trust — in person, on a call, through a tool you had before this one. Anyone holding it can join, and there is no second check.

3. They join with the key and a username. The room code is derived from the key, so nobody has to memorise it.

4. The server relays ciphertext from then on. It can store and forward; it cannot read.