Fingerprints, and how trust is kept over time¶

A fingerprint is a short summary of someone's public keys, computed from the keys themselves. It is not secret, it cannot be chosen, and it is safe to publish. The same key always produces the same fingerprint, and any other key produces a completely different one.

You will see it in two forms, carrying the same value. The words are for reading aloud; the groups are for pasting and for comparing on screen.

Fingerprint for  alice
  spoken   ripple candle fabric ozone velvet hunter
           marble quiver saddle ember lotus  drift
  written  K7QN-3M4X-9WTB-2FDS-8HJR-6VCP-1LZA-4GNE

You check it once, by hand, at enrollment¶

When an administrator approves Alice's enrollment, they compare this fingerprint with Alice over a different channel than the one that carried her request. If the request arrived in chat, verify by voice, video, or in person. An attacker who controls the chat controls the request and anything pasted next to it, so comparing those two proves nothing.

That comparison is the only time a human in your organization ever compares a fingerprint by hand. It is the single moment where a key gets attached to a person. From then on the administrator's signature carries that fact to everyone else, which is why your own client does not ask you to repeat it every time you grant Alice a vault.

How you would know a fingerprint is wrong¶

You would not recognise it as wrong. Recognition is not the mechanism; comparison is. What matters is what the two kinds of failure look like:

• Nothing matches. Almost always mundane: the wrong file, or a stale request from before she regenerated her key.
• Some of it matches. This is the alarming one. A hash of different input differs everywhere, so accidental mismatches are total. A partial match is close to a signature of an attack, because the front of the fingerprint is the cheap part to counterfeit and the part people actually read.

After that, your client remembers¶

Your client keeps a local note of every principal it has dealt with: the fingerprint it saw, when, and whether you personally verified it or it was accepted on the strength of the signature chain. Every later operation compares against that note. If nothing changed, it says nothing.

If a key has changed, the client tells you which kind of change it is, because in this system it can tell. A legitimate key rotation is signed by the old key and countersigned by an administrator:

alice's key changed since you last verified it.
  previously  ripple candle fabric ...   verified by you, 2026-03-04
  now         harbor petal ...
  change is a key rotation, signed by alice's previous key,
  countersigned by priya (admin), 2026-08-01
Accept? [y/N]

There is a middle case: the key changed and an administrator signed off on the new one, but nothing ties it to Alice's old key. That is what it looks like when someone loses their key and enrolls fresh. It is also what it would look like if an administrator's authority were being misused to swap in an impostor's key. The client cannot tell those two stories apart, and it does not try. It asks you to do the one thing that settles it: check the fingerprint with Alice again, by voice or in person, exactly like the first time. If she really did lose her key, you were about to call her anyway.

A substitution with no explanation at all is the third case, and here the client will not let you continue:

alice's key changed since you last verified it.
  the new entry has no valid rotation statement and no enroller
  signature tracing to your organization's root of trust.
Refusing. Do not grant. Contact alice by voice.