Verifying encryption: safety numbers and signatures

End-to-end encryption works without any manual steps, but you can additionally verify that you are talking to the right person and that the code doing the encryption is the code we publish.

Safety number (fingerprint)

Every Secure Rooms user has a safety number - a short fingerprint computed from their public keys (BLAKE2b), displayed in groups of 4 characters. You can see your own safety number on the "Security" page and the safety numbers of other participants in the room's member panel.

To verify a contact, compare safety numbers over a channel you already trust (in person, by phone, via an existing verified channel). If the numbers match, the keys have not been substituted by the server or anyone else. The trust model is "trust on first use + manual verification": keys are pinned automatically, and verification confirms that the pinned key belongs to the right person.

"Signature not verified"

Every message is signed by the sender (Ed25519), and every room key delivery is signed as well, so the server cannot silently substitute a key. If a signature check fails, the message is marked with a red "signature not verified" badge. Treat such messages with caution: it may indicate a key change, a corrupted message, or an attempt to tamper with delivery.

Auditing the cryptography

All encryption code lives in a separate public repository and npm package @wparts/secure-rooms-crypto:

https://github.com/wpartscom/secure-rooms-crypto

The repository contains the format specification (SPEC.md), the threat model (THREAT-MODEL.md), test vectors and the sha256sums.txt of every release. The frontend loads the library as a separate chunk with Subresource Integrity (SRI), and the "Security" page shows the version and build hash of the loaded library, which you can compare against the published release hashes.