Key points
- Inclusion proofs show that a record belongs to a particular tree state.
- Consistency proofs show that a later tree extends an earlier tree without rewriting it.
- Signed checkpoints identify a specific log state.
- Independent monitors or checkpoint gossip are needed to resist split-view histories strongly.
The public-key substitution problem
Encrypting to a public key only helps if the key belongs to the intended recipient. A malicious or compromised directory could replace that key with one it controls, receive the encrypted secret, and then re-encrypt it to the real user. [3]
A transparency log makes key-directory changes auditable. A client can require proof that the returned key appears in a committed tree and compare the current root with a previously trusted checkpoint.
Inclusion and consistency prove different facts
An inclusion proof is a short path of hashes showing that one leaf contributes to a given Merkle root. A consistency proof shows that the leaves committed by an older root remain the same prefix of a newer tree. Neither proof alone establishes that every user saw the same root. [2]
Checkpoints, first use, and independent observation
A client needs a trusted starting point. On first use, it may accept a checkpoint without prior history. After that, retaining checkpoints improves continuity. If a client silently discards a conflicting checkpoint and starts over, it gives up that continuity signal.
A server can present separate internally consistent histories to isolated clients unless roots are compared through gossip or observed by independent monitors. Transparency makes misbehavior detectable under stated observation assumptions; it does not make the server incapable of attempting it.
Common questions.
Does an inclusion proof prove a key belongs to a person?
No. It proves that a particular record is included in a particular tree state. Identity verification and log-governance rules are separate.
What is a Merkle root?
It is a compact hash commitment to all leaves in a particular tree state. Changing a committed leaf changes the root.
Can a transparency log prevent every key-substitution attack?
It can make substitutions detectable under its checkpoint and observation model. Strong split-view resistance requires clients or independent monitors to compare signed roots.
Primary sources
Definitions prefer standards bodies, government guidance, and the first-party SealTask architecture. Links open the complete source.
- 01 IETF Key Transparency Protocol The current IETF protocol draft for auditable identity-to-public-key bindings and consistent views.
- 02 RFC 9162: Certificate Transparency Version 2.0 Append-only Merkle-tree logs, inclusion proofs, and consistency proofs.
- 03 RFC 9180: Hybrid Public Key Encryption The HPKE construction, modes, security goals, and non-goals.
- 04 SealTask security architecture Product-specific encryption boundary, server visibility, protocols, and current limitations.