On the regular web, a domain name is rented from a registrar and a certificate authority vouches for the encryption. Tor throws both away: a Tor v3 onion address is nobody's registered name — it is the service's own Ed25519 public key, base32-encoded into 56 characters with a checksum built in. Whoever holds the matching private key is the site, and no third party needs to vouch for it.
That design flips what "authentic" means. The cryptography proves which key you are talking to; it cannot prove whose key that is. Tying the 56 characters to an operator takes evidence from outside the protocol — a PGP signature on an announcement, not a padlock icon.
Updated
Anatomy of a 56-Character Base32 v3 Address
A v3 address is 35 bytes of binary data run through base32 and printed as 56 lowercase characters plus .onion: a 32-byte Ed25519 public key, a 2-byte checksum, and a 1-byte version tag equal to 0x03 — the layout defined by the Tor Rendezvous Specification v3.
PUBKEY — Ed25519 32 bytes
CHECKSUM 2 bytes SHA3-256
VERSION 0x03
↓ 35 bytes → base32 encode ↓
51–52 chars — the key ~4 chars — checksum +version.onion
The alphabet gives a free sanity check: RFC 4648 base32 uses only a–z and 2–7, so the digits 0, 1, 8, and 9 can never appear in a genuine v3 address — a hostname containing one is malformed before it can be a phish. The checksum is the first two bytes of SHA3-256(".onion checksum" || PUBKEY || VERSION), and Tor Browser validates it locally before building any circuit: one mistyped character means a different key and a failed checksum, so a typo lands you nowhere rather than on a clone.
The 16-character v2 format this replaced was a truncated SHA-1 hash of an RSA-1024 key — short enough to brute-force in bulk, and removed from Tor entirely with version 0.4.6 in 2021. The two formats side by side:
Property
v2 (retired)
v3 (current)
Address length
16 characters
56 characters
What the string encodes
80-bit SHA-1 truncation of an RSA-1024 key
Full 256-bit Ed25519 public key + checksum
Crypto suite
RSA-1024 + SHA-1
Ed25519 + SHA3-256 + ntor handshake
Descriptor privacy
Introduction points readable by any directory that fetched them
Inner layer encrypted — only clients who already know the address can read it
Status
Removed in Tor 0.4.6 (2021)
Current protocol
How Introduction Points & Rendezvous Circuits Work
Six Tor hops, not three — client and service meet at a relay neither controls
A .onion session runs on a six-hop path built in two halves: the client and the service each construct a three-hop circuit to a relay they agree on — the rendezvous point — so neither side ever learns the other's IP address, and the relay in the middle never learns what it's relaying.
The model is a dead drop, not a phone call. The service maintains a public mailbox — an introduction point — where a client can leave a note naming a neutral locker and a one-time password. The service collects the note and meets the client at the locker: the mailbox never saw the locker, and the locker saw both parties without learning where either came from.
1. The service publishes a descriptor
The hidden service picks a few relays as introduction points and keeps long-lived circuits to them, then uploads a signed descriptor to a small set of HSDir directories. Those directories are chosen by a blinded version of the public key that rotates with a time period of roughly a day — so directories cannot enumerate which services exist or track one across days.
2. The descriptor keeps its secrets
Inside the v3 descriptor, the introduction-point data sits behind an extra encryption layer that only a client who already knows the onion address can open. A directory can host the record without learning which relays act as the service's mailbox — one of the quiet improvements v3 made over v2.
3. The client chooses the meeting spot
Having fetched and decrypted the descriptor, the client builds its own three-hop circuit to a relay it selected itself as the rendezvous point, then sends an INTRODUCE1 cell through one of the service's introduction points carrying the rendezvous identity, a one-time cookie, and an ntor handshake.
4. The two circuits splice together
The service verifies the introduction and builds its own three-hop circuit to the same rendezvous point, which joins the two halves into the six-hop data path. The rendezvous relay sees two circuits meet but cannot tell a .onion is involved — and because everything stays inside Tor, there is no exit node anywhere in the path.
Why Most .onion Sites Don't Bother With HTTPS Certificates
The address is already the certificate — but only for the channel, not the operator
HTTPS on a .onion is redundant for encryption because the v3 connection is already end-to-end encrypted to the service's key: the 56 characters in the address bar play the role a CA-issued certificate plays on the clearnet.
The reflex to distrust a plain http:// onion is borrowed from the clearnet, where it means anyone on the path can read the traffic. Inside Tor there is no exit node and no last-mile hop to snoop on — encryption terminates at the service itself, and Tor Browser treats .onion as a secure context. CA-issued onion certificates do exist (DigiCert has offered them since the CA/Browser Forum permitted it, and Facebook's onion famously carried an EV certificate), but all they add is a legal-identity binding that most hidden operators neither want nor need.
What the self-certifying model cannot tell you is who holds the key. Cryptography confirms your circuit ends at the key encoded in the address; whether that key belongs to the operator you meant to reach is outside the protocol's scope — a phishing clone encrypts just as well. That is the hole external signatures close: a PGP-signed announcement ties the 56 characters to a name, which is why the PGP signature verification guide matters as much as the format itself.
The Math Behind Vanity Generators (mkp224o) & Prefix Phishing
Every prefix character multiplies the search by 32 — which is exactly why the tail is what matters
Since the whole address is a public key, its leftmost characters are a pure brute-force problem: generators such as mkp224o churn Ed25519 keypairs until the base32 output opens with a chosen prefix. The cost curve is steep but finite on the left — and absolute on the right:
Prefix length
Keys to test (32n)
Rough cost today
5 characters
~33 million
seconds on one CPU core
6 characters
~1.1 billion
minutes
7 characters
~34 billion
hours on a multicore box
8 characters
~1.1 trillion
days to weeks, parallelized
10 characters
~1.1 quadrillion
months on a serious cluster
All 56 characters
2256 keyspace
beyond physical reach
Legitimate services and phishers run the same tools. A ten-letter vanity prefix like DuckDuckGo's duckduckgo… proves compute was spent, nothing more — the clone that mirrors the first six or seven characters of an address you know is an afternoon of work, not a feat. What nobody can match is the tail, because hitting all 56 characters means breaking the entire 256-bit keyspace.
So read the address from the right: compare the last 10–12 characters before .onion, and confirm the full string against a PGP-signed source before it sees a login — our signed onion address reference keeps the current signed list. The v3 format moved the authenticity question from "which authority vouches for this name" to "which operator signed this key"; the protocol handles the channel, and the last inch — comparing all 56 characters — stays with the reader.