Cryptography

Key transparency

What stops the server from quietly swapping your friend’s key for its own and reading everything? A public, tamper-evident receipt book that your app checks automatically.

A dishonest server could hand you the wrong key for your friend and sit in the middle. Privex stops this by keeping a public receipt book of every key ever published. Your app checks it every time: a swapped key either shows up in the book (and you get an alert) or isn’t there (and your app refuses it).

Every registration and prekey rotation is committed to an append-only Merkle log. When a client fetches a peer’s bundle, it verifies a Merkle inclusion proof against a root signed under a pinned key — and it recomputes the leaf from the received key fields rather than trusting the server’s. Any substitution is detectable; a missing entry is rejected.

Verify before you trust
inclusion proof + signed root under a pinned key
Figure. The client deliberately recomputes the leaf from the key it received, so the server can’t supply a matching-but-fake proof. A safety code (SHA-256 of both identity keys) lets two people confirm out-of-band.

What it defeats

Attack

Server substitutes your friend’s key with one it controls.

Wall

The swapped key must appear in the public book — where your friend’s app spots it — or it isn’t there and your app refuses it.

A substituted key must be in the log (equivocation is detectable via the signed root) or absent (inclusion proof fails → reject).

Attack

Server forges a valid-looking inclusion proof.

Wall

Your app rebuilds the receipt from the key it actually got — a fake can’t match.

Client recomputes the leaf from received fields and checks the root signature under a build-pinned key.

Honest limitation Transparency only works if clients actually check — which Privex does automatically on every key fetch — and if the client binary isn’t silently modified. Open-source + reproducible builds back this up. Periodic public root publication is scheduled before scale.