The idea
Linking a name to a public key usually needs a third party. A certificate authority signs a statement that a key belongs to a domain, or a directory answers when you ask for someone’s key. Both have to be reachable and trusted.
A self-certifying identifier removes that step by making the name out of the key. In their 1999 paper on SFS, a secure network file system, David Mazières and colleagues introduced self-certifying pathnames: file names that, in their words, effectively contain the appropriate server’s public key. Each pathname had the form Location:HostID, where HostID was a cryptographic hash of the server’s public key and its location. A client that knew the pathname could ask the server for its key and check the reply against the HostID itself, with no separate key management in the file system.
The same pattern appears in later systems where devices or services need names that nobody issues, including the examples below.
How a check works
When a peer presents a key and claims an identifier, the verifier does two things:
- Recompute the identifier from the key. Hash or encode the presented public key the same way the system defines, and compare the result with the claimed identifier. If they differ, reject the key.
- Check that the peer holds the private key. A public key can be copied by anyone, so a match alone proves nothing about who sent it. The peer signs a fresh challenge, or the message itself, and the verifier checks that signature with the key it just matched.
The first step relies on the hash. NIST’s key management guidance describes approved hash functions as preimage-resistant and collision-resistant: finding an input that maps to a given output, or two inputs that map to the same output, is computationally infeasible. That is what stops an attacker from producing a different key that yields your identifier.
Examples
| System | Identifier | How it is derived |
|---|---|---|
| SFS | HostID in a pathname | Hash of the server’s public key and location |
| libp2p | Peer ID | The encoded public key itself if it is short, otherwise its SHA-256 hash |
| Tor onion services | Onion address | The service’s Ed25519 public key plus a checksum and version, in base32 |
The libp2p and Tor cases show that an identifier can contain the key rather than a hash of it. The libp2p specification embeds keys that serialise to 42 bytes or fewer, which covers Ed25519, and hashes longer ones. Tor’s onion address carries the full 32-byte Ed25519 public key. Either way, the identifier can be checked against a presented key without asking anyone.
Mesh networks use the same approach. In Offline Protocol’s mesh SDK, each device’s off1 address is derived from its Ed25519 identity key, which makes it self-certifying, and the security documentation notes that verification binds the presented key to that address but does not establish a person’s role or permission.
What it does not tell you
A self-certifying identifier answers one question: does this key belong to this name? It leaves others open.
- Who is behind it. An attacker can generate a key and a valid identifier just as easily as anyone else. The identifier is only as trustworthy as the way you received it, such as a QR code shown in person, a link from someone you already trust, or trust on first use.
- What a human-readable name means. Identifiers look random, so systems map friendly names onto them. SFS used symbolic links for this. That mapping is a separate trust decision, and a name that anyone can claim should never be accepted automatically.
- What the holder may do. Proving control of a key grants no permissions. The application decides that after enrolling the identity.
When the key changes or leaks
Because the identifier is tied to one key, it cannot survive a change of key. Key rotation for a self-certifying identity means a new identifier, and every contact has to learn it. The SFS paper describes publishing under both names or leaving a forwarding pointer at the old one.
A leaked key is worse. Whoever holds it can act as that identifier, and the SFS paper notes that an attacker with a disclosed key could serve a false forwarding pointer. SFS therefore added revocation certificates, signed with the compromised key’s own private key, that clients check before trusting a pathname. Any system built on self-certifying identifiers needs some way to spread revocations, especially when devices are offline and cannot ask a server.