KEY TRANSPARENCY
How a directory can make undetected key substitution harder.
End-to-end encryption depends on obtaining the right public key for the intended recipient. If the same service that routes messages can silently replace that key, it can place itself between users without breaking the encryption algorithm.
Manual fingerprint comparison can detect substitution, but it does not scale to every contact, device and key rotation. Key transparency gives the directory an accountable history. Clients receive cryptographic evidence that a key belongs to a consistent, append-only view that can be monitored.
The directory remains trusted for availability and account policy. It should no longer be trusted to equivocate invisibly.
A signed directory response is not enough
A service can sign a false key just as easily as a true one if it controls the signing key. A signature proves which service produced the response, not that every client received the same response.
Transparency adds a data structure whose state commits to all accepted updates. The service signs tree heads, and clients verify proofs connecting a requested value to that committed state.
Accountability comes from consistency across observations, not merely authenticity of one observation.
Two trees answer different questions
Current key-transparency designs combine an append-only log with a searchable map. The log records the sequence of updates. The map lets a client obtain the current value for a particular account label efficiently.
An inclusion proof answers whether an entry is committed under a tree head. A consistency proof answers whether a later tree extends an earlier one without rewriting history. A search proof connects a label and version to its current value.
Each proof covers a different claim. Treating any Merkle proof as generic evidence of correctness obscures the security property being checked.
VRFs hide the directory label
A public map keyed directly by email address or phone number would enable enumeration. The protocol can derive a search key using a verifiable random function under the service’s VRF key.
The service computes a pseudorandom-looking output for the account label and supplies a proof that the output is correct. A client can verify the mapping without learning the VRF secret key.
This makes the tree position difficult to predict without querying the service. It does not hide the label from the service itself, and access patterns may still reveal which entries a client monitors.
Commitments separate storage from disclosure
Directory values can be committed in the searchable structure while their openings and plaintext values are returned only to authorized clients. This reduces what a public auditor learns from traversing the tree.
Commitment randomness must be generated correctly and associated with the exact version. Reusing or exposing openings can reveal relationships between updates.
The structure can prove that a value was committed consistently. It does not decide which clients are authorized to learn that value.
Split views are the central attack
A malicious service may show one victim a tree containing an attacker-controlled key and show everyone else a benign tree. Each view can be internally valid.
Detection requires tree heads to cross trust boundaries. Clients can retain previous heads, exchange them indirectly, submit them to auditors or rely on witnesses that refuse to endorse inconsistent histories.
A transparency log observed by only one client is a tamper-evident diary, not a globally accountable system.
Monitoring is an active protocol
Users need evidence not only for the key they retrieve today but for unexpected changes to their own labels and important contacts. Monitoring checks new tree heads and follows relevant versions over time.
A client that reinstalls and loses its last trusted head may be unable to distinguish a legitimate current history from a targeted fork. State backup or independent auditors can provide continuity.
Transparency therefore creates a small but meaningful durable state requirement at the edge.
Provisional entries trade latency for assurance
An update may need to become usable before it is included in a fully audited tree head. Protocols can represent provisional credentials with different assurance from established entries.
This improves availability for a new device or urgent key replacement but creates a period in which monitoring has not supplied the same consistency evidence.
Applications should expose that distinction to policy. Treating provisional and established keys identically discards information the protocol worked to preserve.
Account recovery is a key update
When a user loses every device, the service may authorize a new key through an account-recovery process. Transparency can make the change visible; it cannot determine whether recovery was legitimate.
A fraudulent recovery will still produce a consistent log entry. Contacts or the label owner can detect the unexpected change and react, but prevention depends on the recovery policy and any independent approval mechanism.
Visibility is not validity. It changes silent substitution into an accountable event.
Availability remains centralized
The service can refuse lookups, delay updates or omit selected clients. Cryptographic proofs make forged responses detectable, but they do not force the directory to respond.
Caching, mirrors and auditors can reduce some dependency. Privacy constraints may limit how much directory data can be replicated publicly.
The client must verify every layer
A client needs to validate signed tree heads, log consistency, search proofs, VRF proofs, commitments, versions and application credentials. Skipping one layer can preserve the appearance of transparency while losing its intended property.
Verification also needs algorithm and configuration agility. A tree head should bind the hash, signature suite, VRF suite, tree parameters and deployment mode so that clients do not interpret one structure under another profile.
Accountable distribution, not automatic identity
Key transparency does not prove that an account label belongs to a real-world person. It proves that the service’s assertions about that label and its key history are committed consistently and can be audited.
That narrower property closes an important gap in end-to-end encryption. Strong message cryptography is of limited value if key distribution can be altered silently.
A key directory should be accountable because the directory is part of the cryptographic protocol.
