The address is the key

The common phrasing is that onion addresses are self authenticating. True, and the word hides how simple the reason is.

What follows from it

If the address is the key, then reaching the address correctly means reaching whoever holds the matching private key. No certificate authority is involved. No registrar can reassign it. There is nobody in the middle who could be persuaded, compelled or hacked into pointing the name somewhere else.

That is the entire security model and it is unusually small. On the ordinary web, a name and a key are separate things glued together by a chain of trusted parties, and most of the attacks are against the glue. Here there is no glue.

Where the responsibility lands instead

On you, holding the string. Since there is no authority to check the address against, the address you have is the address you get. Everything the model gives you is downstream of having the right 56 characters, which is why so much of this site is about the characters.

This is the trade. No third party can betray you, and no third party can save you from a wrong copy. There is no revocation list to consult and no warning page to appear.

The common misreading

People hear self authenticating and take it to mean the address vouches for the people running the service. It does not. It proves that the thing answering holds the private key for that address. Whether that thing is honest, competent, or the same operation it was last month is not addressed at all.

Cryptographic identity and human trustworthiness are different questions, and the address only answers the first. Somebody could hand over their private key tomorrow and the address would keep authenticating perfectly to a different owner.

Second misreading

That the key in the address is the one used to sign messages you might see. It is not necessarily. A market may publish a separate signing key for announcements, and the relationship between that key and the address is a policy, not a fact of the protocol. See what a signature actually proves.

A consequence for mirrors

Because the name is the key, an operator who wants a second address has to generate a second keypair. They cannot point a new name at the old key, because the name would come out as the old address. That is why a mirror list is a list of independent keys rather than a list of aliases.

It also explains why vanity prefixes take work. Getting an address that starts with readable letters means generating keys until one of them encodes that way. The key is not chosen to fit the name, the name falls out of the key.

What would move this

A protocol redesign that put a lookup layer between the name and the key. That would be a fundamental change of character rather than a version bump, and it would reintroduce exactly the third parties the design exists to avoid. Nobody is proposing it.

A weaker version could arrive by habit rather than by protocol. If people routinely reached the market through a service that translates a short memorable name into an onion address, the practical model would gain a third party even though the protocol did not. That is worth watching for, and it would not change this statement, only the number of people it protects.

• Anatomy of an onion address
• Each mirror is its own key
• Why the padlock is irrelevant here