Key Transparency: Proof Your Encrypted Chat Isn't Intercepted

End-to-end encryption makes a strong promise: only the people in a conversation can read it. There is a quiet condition hidden inside that promise. Your device encrypts to a key, and it trusts that the key belongs to the person you meant. If the server that hands out keys ever lies, even once, the encryption works perfectly and protects the wrong person.

This is the key-substitution problem, and it is one of the least discussed weaknesses in secure messaging. Key transparency is the answer the industry has been building toward for a decade. VOIDEX makes it a core part of VOIDEX Messenger: every device key is written to a public, append-only log, and clients refuse keys that are not in it.

The problem hiding in the phone book

To send you an encrypted message, my device needs your public key. It cannot ask you directly, because we have not exchanged anything yet. So it asks the service's key directory, a kind of phone book that maps your account to your devices' public keys.

Now imagine that directory is compromised. That could be a malicious insider, an attacker who has breached the servers, or a government order compelling the provider to cooperate. The directory could return a key controlled by the attacker instead of yours. My device would encrypt to that key without complaint. The attacker decrypts, reads, re-encrypts to your real key and forwards it. We both see a working conversation. Nothing looks wrong.

This is a classic man-in-the-middle attack, performed at the one point that end-to-end encryption cannot protect by itself: key distribution.

Safety numbers help, if people use them

Most serious messengers offer a manual defence. Signal calls it safety numbers, WhatsApp calls them security codes: a fingerprint derived from both parties' keys that you can compare in person or over another channel. If the fingerprints match, no substitution happened.

It works, and it is worth doing for sensitive contacts. The problem is human. Very few people compare fingerprints, and fewer still repeat the check every time a contact gets a new phone. A defence that depends on everyone doing tedious work will mostly go unused. What is needed is a system that makes cheating by the server detectable automatically, for everyone, all the time.

The inspiration: Certificate Transparency

The web solved a similar problem first.

Browsers trust hundreds of certificate authorities to vouch for which key belongs to which website. In 2011 the Dutch authority DigiNotar was breached, and fraudulent certificates for Google domains were issued and used against real users. The system had no way to notice a certificate that should never have existed until it was already being abused.

Google engineers responded with Certificate Transparency, published as RFC 6962 in 2013. The idea is simple and powerful: every certificate must be recorded in public, append-only logs before browsers will accept it. Anyone can monitor those logs. A domain owner can watch for any certificate issued in their name. A rogue certificate can still be issued, but it cannot be issued secretly. Chrome made Certificate Transparency mandatory for new certificates in 2018.

The key technology is a Merkle tree. Every entry is hashed, pairs of hashes are hashed together, and so on up to a single root hash that summarises the whole log. The log operator signs that root, producing a signed tree head. Two kinds of short proofs make the structure trustworthy:

• An inclusion proof shows that a specific entry is in the tree, using only a handful of hashes.
• A consistency proof shows that a newer version of the tree contains everything in an older version, meaning nothing was removed or rewritten.

Together, these make the log append-only in a verifiable way. The operator can add entries. It cannot quietly change history without producing mathematically contradictory evidence.

From certificates to messaging keys

Applying the same idea to messengers took years of research. Academic designs such as CONIKS explored it in 2015, and Google worked on a Key Transparency project. The largest real deployment came in April 2023, when WhatsApp announced key transparency built on an auditable key directory, with the goal of letting clients automatically verify that the keys they receive are consistent. Apple followed with iMessage Contact Key Verification, which it described in detail and which uses a verifiable log to detect key substitution.

These are important steps by capable teams, and they point in the same direction: the key directory should be accountable, not simply trusted.

What a key transparency log actually guarantees

It helps to be precise. Key transparency does not make key substitution impossible. It makes it visible.

If a server wants to show me a false key for you, it has two options. It can put that false key in the public log, in which case your own device, which checks the log for its own keys, can see that a key it never created has been published in your name. Or it can keep the false key out of the log, in which case a client that refuses unlogged keys will not accept it.

The remaining trick for a dishonest operator is a split view: showing one version of the log to you and a different version to me. That is why logs are paired with gossip and independent witnesses. If multiple parties compare the signed tree heads they have seen, a fork shows up as two signed roots for the same log size that cannot both be true. The operator's own signatures become the proof of misbehaviour.

How VOIDEX implements key transparency

VOIDEX built key transparency into the foundation of VOIDEX Messenger rather than adding it later. Here is what it does:

• Every device key change is logged. When a member adds a device, publishes new keys or removes a device, the change is appended to a public, append-only Merkle log in the style of RFC 6962.
• Tree heads are signed with hybrid signatures. Each signed tree head carries both an Ed25519 and an ML-DSA-65 signature. The log's integrity does not rest on elliptic curves alone, in keeping with VOIDEX's approach to hybrid post-quantum cryptography.
• Clients check, and refuse. VOIDEX clients check the keys they receive against the log and refuse keys that are not in it. A key the server tries to slip in without logging is not used.
• Anyone can audit it. Public endpoints let anyone fetch the signed tree heads and proofs and verify the log for themselves. You do not need to be a VOIDEX member or employee to check it.
• An independent witness watches it. A separate witness follows the log over time, so a rewrite or split view would be caught by something other than VOIDEX's own servers.

Key transparency works alongside the rest of VOIDEX's design. Direct messages use hybrid X25519 plus ML-KEM-768 key agreement and a double ratchet with post-quantum re-keying, which we explain in Harvest Now, Decrypt Later. Device identities are signed with Ed25519 plus ML-DSA-65. Groups and private VOIDEX Channels use MLS (RFC 9420). Calls run over WebRTC with DTLS-SRTP, and the call setup is sealed under the conversation key so the server cannot swap the fingerprint used to secure the media.

Keys are created on members' own devices. VOIDEX servers hold public keys and ciphertext, never private keys.

Verify, don't trust

Key transparency belongs to a larger philosophy: a security claim is only as good as the ability of outsiders to check it. That is why VOIDEX publishes its cryptographic core as open source and documents its design in a public security report. Open code shows what the client is supposed to do. A public log shows what the server actually did. We explore that principle further in Verify, don't trust.

It also sets honest limits. Key transparency protects the distribution of keys. It does not protect a device that has itself been compromised, and it does not make public content private. Public posts in VOIDEX Space and Public channels are designed to be seen and are clearly labelled as not end-to-end encrypted.

Why this matters now

As encryption spreads, attackers look for the parts it does not cover. Intercepting ciphertext is useless against good end-to-end encryption, so the rational target becomes the key directory: compel it, breach it or corrupt it. Key transparency turns that single point of silent failure into a public record, where cheating leaves evidence that anyone can find.

For a platform that asks people to trust it with their most private conversations, that is the right standard. Not "trust us", but "check us".

VOIDEX is invite-only and free. Request access to join, or read the VOIDEX security report to see how every key is put on the record.

Sources

• RFC 6962, Certificate Transparency (June 2013): https://www.rfc-editor.org/rfc/rfc6962
• Meta Engineering, "Deploying key transparency at WhatsApp" (13 April 2023): https://engineering.fb.com/2023/04/13/security/whatsapp-key-transparency/
• Apple Security Research, "Advancing iMessage security: iMessage Contact Key Verification": https://security.apple.com/blog/imessage-contact-key-verification/
• RFC 9420, The Messaging Layer Security Protocol: https://www.rfc-editor.org/rfc/rfc9420