Hey hackers - onion services solve a strange problem: publishing an endpoint on a network that refuses to have an address book, a DNS root, or anyone in charge of naming.
These onion services run without DNS, without a registrar, without a certificate authority - the key pair is the name, and everything else follows from that.
TL;DR: A v3 onion address is fifty-six characters of base32 derived from an ed25519 public key, so the address literally is the identity: change the key, you are a different service. Discovery runs through distributed hidden-service directories, not name resolution; connections rendezvous through a third party so client and service never learn each other's network location. v2 died in 2021 with its 80-bit keys; v3 brought stronger keys, proof-of-work against intro floods, and optional client authorization.
Traffic analysis remains the residual risk - encryption hides content, never timing.
Neighbors: directories, engines, the DNS side.
That property cuts both ways. Key leaked, name stolen: the clone runs with full credibility because the address itself verifies for every visitor. Key lost, name gone: no recovery process exists, no registrar to appeal to, no certificate reissue - the service simply ceases to exist everywhere. Operators treat the private key the way a bank treats a master seal, and the ones who do not get to explain to their users why the site they trusted is now serving somebody else's page.
Enumeration does not work the way web people expect: there is no full list of onion services anywhere, because the descriptor spread is computed from addresses people already hold. Onion services exist for holders of the address and for the directory nodes storing the record - everything else about them stays dark by construction, which is why a new address gets discovered through a link someone posted rather than through a crawl of a master index.
Descriptors carry their own clock: the service republishes on a fixed interval, each record expires on schedule, and the directory nodes rotate who holds what over time. Restart the service, and the world takes minutes to agree you are back; walk away without republishing, and the record ages out while the origin server still answers on localhost.
The handshake itself is the elegant part: the client picks a rendezvous point on its side of the network, sends an introduce message through an introduction point to the service, and the service builds its own circuit to the same rendezvous point. Two separate three-hop circuits meet in the middle, end-to-end encryption runs across the join, and neither endpoint learns the other's IP - the rendezvous relay is the only node that can see both circuits touching it, and it sees them as opaque.
Nothing in that flow resembles DNS because nothing in that flow is name resolution. The address determines storage locations, not servers; the service can be behind NAT on a laptop, hosted in a datacenter, or offline entirely, and the network's view does not change. The DNS-gap problem that keeps subdomain-takeover hunting busy simply does not exist on a network where names never pointed at machines - and the onion services that live there inherit no zone files to leak, no records to hijack, and no expiry dates to miss.
What no layer protects is timing. A sufficiently resourced observer watching both ends of a rendezvous can correlate the packet rhythms entering one side with the rhythms leaving the other, and that traffic-confirmation attack is the standing residual risk of the design - content confidentiality holds, communication patterns leak.
Operator-facing endpoints live with this daily: the endpoint's location stays hidden while its rhythm stays visible.
Per-hop visibility is narrower than people assume. Directory nodes see that a descriptor exists and when it was refreshed, not who fetched it beyond relay-level context. Introduction points see the introduce message transit, not the connection. The service's own relay sees circuits reaching out, not the client's network location. None of the parties hold the full picture; a global adversary who is all of them at once is the threat model the protocol documents assume and the threat model no configuration flag removes.
The craft is in what surrounds those three lines: key backup discipline, keeping the hostname file out of version control, and deciding whether the service should stay reachable when the origin application is down.
Latency behaves differently than on the open web: circuits age out on a timer and get rebuilt underfoot, descriptor refreshes take minutes to propagate after a restart, and the first request after idle often pays the cost of a fresh handshake. Teams porting a web app onto an onion endpoint discover that their connection pooling and keep-alive assumptions were written for a network with stable routes - this one moves underneath them by design.
Health checks adapt too: a TCP probe that assumes instant SYN will report false outages all day, so monitoring tools built for clearnet services need the handshake window widened and the retry patience extended before their dashboards stop lying. The endpoint is up; the circuit simply took the scenic route.
Key custody gets its own checklist: back up the private key offline before the first public link ships, keep the hostname file out of containers and repositories, and rehearse the restore - a key archive nobody has ever loaded is a hypothesis, not a backup. The restore rehearsal catches the quiet killers: permissions that do not survive the copy, an archive encrypted with a passphrase nobody documented, a deployment that regenerated the key on boot and published a different address to every environment.
Key loss: the operator's disk dies without a backup, the service vanishes, and the community mourns a name that cannot be reissued. And phishing: lookalike addresses and mirrored pages harvest users who verify by memory instead of by comparison.
The phishing path deserves the emphasis because it needs no compromise at all. Fifty-six characters are too long to type reliably, so readers click links - and links arrive wherever links arrive: forums, DMs, directory rows, search results. A single transposed pair yields a valid-looking address serving a page cloned from the original, and the clone kits that automate clearnet impersonation automate onion impersonation the same way.
The verification habit that survives every iteration: obtain the address from a second channel you already trust, compare it character by character, and never accept an address as confirmation of its own identity.
Rotation is the countermeasure operators plan for and rarely practice: generate a fresh key pair, publish the new address through every channel the old one used, keep both running through a transition window, then retire the old address deliberately. Done badly, rotation splits the user base; done never, the first compromise has no response. The teams that handle it well schedule it the way they schedule certificate renewal - an event with a date, an owner, and a communication template, even though no authority forces it.
Seizures round out the picture: enforcement takes servers, not naming rights, because no registry exists to serve a takedown against. A shuttered host leaves a dead address that keeps resolving to nothing, and the traffic waiting at that address is exactly what the next operator's mirror arrives to catch - which is why the verification habit matters most in the weeks after a takedown.
Readers carry their own half of the contract: bookmark the address instead of the link that carried it, confirm updates through a channel outside the page itself, and treat a sudden redesign - new login form, new wallet field, new download button - as a reason to re-verify rather than a reason to hurry.
These onion services run without DNS, without a registrar, without a certificate authority - the key pair is the name, and everything else follows from that.
TL;DR: A v3 onion address is fifty-six characters of base32 derived from an ed25519 public key, so the address literally is the identity: change the key, you are a different service. Discovery runs through distributed hidden-service directories, not name resolution; connections rendezvous through a third party so client and service never learn each other's network location. v2 died in 2021 with its 80-bit keys; v3 brought stronger keys, proof-of-work against intro floods, and optional client authorization.
Traffic analysis remains the residual risk - encryption hides content, never timing.
Neighbors: directories, engines, the DNS side.
The address is the key
The naming model behind onion services compresses everything into fifty-six characters. Generate an ed25519 key pair; the public half, a version byte, and a checksum derived through SHA3 get packed and base32-encoded into the address a reader types. Nothing is registered anywhere. The address does not resolve the way a domain resolves - it is a fingerprint of the key the service holds, which means possession of the private key is possession of the name and no third party can revoke, sell, seize, or transfer it.That property cuts both ways. Key leaked, name stolen: the clone runs with full credibility because the address itself verifies for every visitor. Key lost, name gone: no recovery process exists, no registrar to appeal to, no certificate reissue - the service simply ceases to exist everywhere. Operators treat the private key the way a bank treats a master seal, and the ones who do not get to explain to their users why the site they trusted is now serving somebody else's page.
Enumeration does not work the way web people expect: there is no full list of onion services anywhere, because the descriptor spread is computed from addresses people already hold. Onion services exist for holders of the address and for the directory nodes storing the record - everything else about them stays dark by construction, which is why a new address gets discovered through a link someone posted rather than through a crawl of a master index.
Descriptors carry their own clock: the service republishes on a fixed interval, each record expires on schedule, and the directory nodes rotate who holds what over time. Restart the service, and the world takes minutes to agree you are back; walk away without republishing, and the record ages out while the origin server still answers on localhost.
| Component | Role |
|---|---|
| ed25519 key pair | generates the address; signs everything |
| Descriptor | signed record published for discovery |
| Hidden-service directories | store and serve descriptors |
| Introduction points | stable contact handles for the service |
| Rendezvous point | where client and service circuits meet |
Discovery without a directory service
When somebody requests a descriptor, the ask lands on a set of directory nodes chosen from the address itself - the same fifty-six characters that identify the service decide where its records live, so client and service independently compute the same storage location without either one broadcasting where they are. The service uploads its signed descriptor there on a schedule; clients fetch it, learn which introduction points to use, and start the handshake.The handshake itself is the elegant part: the client picks a rendezvous point on its side of the network, sends an introduce message through an introduction point to the service, and the service builds its own circuit to the same rendezvous point. Two separate three-hop circuits meet in the middle, end-to-end encryption runs across the join, and neither endpoint learns the other's IP - the rendezvous relay is the only node that can see both circuits touching it, and it sees them as opaque.
Nothing in that flow resembles DNS because nothing in that flow is name resolution. The address determines storage locations, not servers; the service can be behind NAT on a laptop, hosted in a datacenter, or offline entirely, and the network's view does not change. The DNS-gap problem that keeps subdomain-takeover hunting busy simply does not exist on a network where names never pointed at machines - and the onion services that live there inherit no zone files to leak, no records to hijack, and no expiry dates to miss.
What the network can and cannot see
Encryption here has layers, and each layer answers a different question. The onion wrapping gives every relay only the instructions meant for it; the end-to-end layer between client and service protects the actual traffic from the rendezvous point inward; TLS inside the tunnel protects the payload from anyone without the keys.What no layer protects is timing. A sufficiently resourced observer watching both ends of a rendezvous can correlate the packet rhythms entering one side with the rhythms leaving the other, and that traffic-confirmation attack is the standing residual risk of the design - content confidentiality holds, communication patterns leak.
Operator-facing endpoints live with this daily: the endpoint's location stays hidden while its rhythm stays visible.
Per-hop visibility is narrower than people assume. Directory nodes see that a descriptor exists and when it was refreshed, not who fetched it beyond relay-level context. Introduction points see the introduce message transit, not the connection. The service's own relay sees circuits reaching out, not the client's network location. None of the parties hold the full picture; a global adversary who is all of them at once is the threat model the protocol documents assume and the threat model no configuration flag removes.
v2 died so v3 could live
v2 addresses carried eighty bits of security and their structure had started showing cracks - address-space grinding made certain attacks practical, and a generation of research had whittled the assumptions down further. Tor retired v2 in October 2021 with hard deadlines rather than a grace period, and every address of that generation stopped resolving as designed.
v3 answers with ed25519 keys, a fifty-six-character address format, and descriptor security tied to the same primitive modern TLS is moving toward - the same keys guarding onion services now guard the web's next protocol generation.
v3 also shipped the abuse defenses the old protocol never had: proof-of-work requirements on introduction when a service is under request floods, turning a connection storm into a computational bill the attacker pays and honest clients tolerate; optional client authorization where descriptors are encrypted so only holders of a provisioned credential can even learn the introduction points.
Neither is default-on - services that expose high-value identity use both, and services that want to stay findable use neither, because authorization hides you from everyone, not only from attackers.
v3 answers with ed25519 keys, a fifty-six-character address format, and descriptor security tied to the same primitive modern TLS is moving toward - the same keys guarding onion services now guard the web's next protocol generation.
v3 also shipped the abuse defenses the old protocol never had: proof-of-work requirements on introduction when a service is under request floods, turning a connection storm into a computational bill the attacker pays and honest clients tolerate; optional client authorization where descriptors are encrypted so only holders of a provisioned credential can even learn the introduction points.
Neither is default-on - services that expose high-value identity use both, and services that want to stay findable use neither, because authorization hides you from everyone, not only from attackers.
Running one: the operational reality
Hosting onion services is deceptively small: a torrc flag, a port mapping, and the key material. Tor generates the key pair on first start, writes the address to a hostname file, and serves the service from that point on - one hidden-service line maps a local port to a public onion endpoint, and the same three lines configure ninety percent of the network's services.The craft is in what surrounds those three lines: key backup discipline, keeping the hostname file out of version control, and deciding whether the service should stay reachable when the origin application is down.
| Choice | Trade |
|---|---|
| Standard onion (both sides relayed) | full anonymity, extra latency |
| Single onion (service side direct) | faster; service trades away one layer |
| Client authorization on | private; you manage the credential list |
| Proof-of-work preference | flood resistance; honest clients compute |
Health checks adapt too: a TCP probe that assumes instant SYN will report false outages all day, so monitoring tools built for clearnet services need the handshake window widened and the retry patience extended before their dashboards stop lying. The endpoint is up; the circuit simply took the scenic route.
Key custody gets its own checklist: back up the private key offline before the first public link ships, keep the hostname file out of containers and repositories, and rehearse the restore - a key archive nobody has ever loaded is a hypothesis, not a backup. The restore rehearsal catches the quiet killers: permissions that do not survive the copy, an archive encrypted with a passphrase nobody documented, a deployment that regenerated the key on boot and published a different address to every environment.
Failure modes: clones, key loss, phishing
Three failure modes dominate onion services deployments, and all three trace back to the address-is-the-key property. Key compromise: the private key leaks from a backup archive or an unpatched host, and the attacker runs the same address from anywhere - visitors cannot distinguish the clone because the address itself is the verification token.Key loss: the operator's disk dies without a backup, the service vanishes, and the community mourns a name that cannot be reissued. And phishing: lookalike addresses and mirrored pages harvest users who verify by memory instead of by comparison.
The phishing path deserves the emphasis because it needs no compromise at all. Fifty-six characters are too long to type reliably, so readers click links - and links arrive wherever links arrive: forums, DMs, directory rows, search results. A single transposed pair yields a valid-looking address serving a page cloned from the original, and the clone kits that automate clearnet impersonation automate onion impersonation the same way.
The verification habit that survives every iteration: obtain the address from a second channel you already trust, compare it character by character, and never accept an address as confirmation of its own identity.
Rotation is the countermeasure operators plan for and rarely practice: generate a fresh key pair, publish the new address through every channel the old one used, keep both running through a transition window, then retire the old address deliberately. Done badly, rotation splits the user base; done never, the first compromise has no response. The teams that handle it well schedule it the way they schedule certificate renewal - an event with a date, an owner, and a communication template, even though no authority forces it.
Seizures round out the picture: enforcement takes servers, not naming rights, because no registry exists to serve a takedown against. A shuttered host leaves a dead address that keeps resolving to nothing, and the traffic waiting at that address is exactly what the next operator's mirror arrives to catch - which is why the verification habit matters most in the weeks after a takedown.
Readers carry their own half of the contract: bookmark the address instead of the link that carried it, confirm updates through a channel outside the page itself, and treat a sudden redesign - new login form, new wallet field, new download button - as a reason to re-verify rather than a reason to hurry.