Dice

The server does not choose the dice after the bet. Both players can check the roll on this phone.

1. Before anyone rolls, the server creates a hidden key and shows only a lock. The lock is the SHA-256 fingerprint of that hidden key. Copy it.
2. You type your key. The other player types the target player key. This duel has its own roll number.
3. The dice are HMAC-SHA256 of the hidden key and the text source key:target key:roll number. The first byte of that output, modulo 6, plus 1, is the source die. The second byte is the target die. The higher die wins the points.
4. After the dice land, the hidden key is opened. Check fairness hashes it and compares it with the lock. Decode HMAC-SHA256 shows those two bytes becoming the two dice.

Why this is fair

If the server or a developer changed the hidden key after the lock was shown, the hash would not match the lock.

If a die was changed after the bet, it would not match HMAC-SHA256 of the hidden key and the two keys both players locked.

The phone does not invent the roll. It only shows the result and lets you recompute it (ask ai for this).

Signal protocol

Personal text is sealed on your phone before it is sent. The server stores ciphertext, not the words.

1. Each account creates an identity key on the device. Only the public key is uploaded.
2. Both phones do ECDH with those public keys, then HKDF. They reach the same root key. The private keys never leave the phone.
3. Each message gets its own AES-GCM key from that root, the sender, the peer, and a counter. The body sent to the server starts with sig1.
4. The other phone derives the same message key and opens the text. A phone without the private key sees “Encrypted message”.

The server and a developer can see who wrote, when, and the ciphertext length. They cannot read the text, because they do not have either private key. If a public key is replaced, the next message no longer opens, so the swap is visible.