«Tor», «onion», «dark web», «hidden service»: words that travel together and get confused just as often. This sheet lines up the concepts you need for the howtos in the series: what onion routing is, how a .onion address works, why everyday DNS doesn’t resolve it, and — honestly — what it protects and what it doesn’t. No mysticism: it’s network engineering, and it can be explained.
Deep web ≠ dark web
Two terms endlessly mixed up. The deep web is everything search engines don’t index: your webmail, online banking behind a login, company intranets, private databases, pages behind a form. It’s a huge, perfectly normal slice of the web — nothing to do with Tor. The dark web is instead a small slice of the deep web, reachable only with dedicated software (overlay networks like Tor): exactly the .onion onion services we’re talking about here. So, strictly: whenever we say «dark web» we mean .onion services on Tor — in a technical sense, not as a synonym for «shady place».
There’s a rung deeper still, and it’s a concept worth isolating: call it the «deep dark web». It’s the slice of .onion services you can’t reach even knowing the address — you need a private key and, in effect, an invitation. It’s the stealth layer of the dark web: not indexed, not «browsable», found by no search engine. Either you’re on the list of who may enter, or for you that service does not exist. It’s the most hidden level — we open it in detail later.
The dark web isn’t only Tor: the other networks
Before diving into Tor, a clarification that avoids the commonest misconception: «dark web» is not a synonym for Tor. There are at least four different anonymity networks, parallel and separate — each with its own addresses, protocols, communities and content. They don’t talk to each other: you can’t reach a .i2p from Tor, nor a .loki from I2P.
| Network | Access | Addresses | Scale | Content |
|---|---|---|---|---|
| Tor | Tor Browser / tor daemon | .onion |
The largest | Marketplaces, leak sites, forums, news: everything. The easiest to use. |
| I2P | I2P client (i2pd) |
.i2p |
Medium | File sharing, technical forums, mail, torrents. No exit nodes by default: everything stays inside I2P. |
| Lokinet | Lokinet client (Oxen) | .loki |
Small | Few sites, mostly promo or experimental. Most of Oxen goes through Session (messaging), not .loki sites. |
| Freenet / Hyphanet | Hyphanet client | Hash keys (USK@…) |
Small | Distributed archive: documents, texts, static files that stay online even if whoever published them disappears. Not real-time. |
The kind of content is similar — leaks, forums, file sharing, markets, activism — but the population differs: Tor is the mainstream; I2P is more technical (developers, anonymous torrents) and doesn’t «exit» to the clearnet; Lokinet is still niche and ransomware groups don’t make sites there (they use Session to communicate and Tor for leak sites); Freenet/Hyphanet is a key-addressed archive, with no real-time interaction.
The proportions are estimates, not a census, but the order of magnitude is clear: Tor is the vast majority of the «dark web» people know, I2P a far more technical slice, Lokinet and Freenet together a niche. Concretely, the data leaks published through double extortion live on Tor — which is what the onionwatch article is about. That’s why looking for yourself «on the dark web» means, almost always, looking on Tor — and Tor is what the rest of this sheet is about. The other networks exist and are active, but they’re separate ecosystems.
Onion routing: three hops, not one
A normal connection goes from you to the server in a straight line: your IP is written on the packet, and whoever is in the middle (provider, server) knows who talks to whom. Tor breaks that link by routing traffic through three relays picked at random in its network:
- Guard (entry): the only one that knows your IP, but not where you’re going.
- Middle (middle): just a bridge — it knows neither who you are nor where you go.
- Exit: delivers the traffic to the destination and knows the target, but not who you are.
The «onion» name comes from how the packet is encrypted: the client wraps it in several layers of encryption, one per relay. Each node peels its own layer and sees only the next node’s address. No single relay ever sees who and where at once: that’s the point, and the reason for three hops. Two wouldn’t be enough (guard and exit together could link the two ends); three is the minimum so no single node closes the loop.
Who keeps the list of relays: the directory authorities
For the client to build a circuit, it must know which relays exist and which to trust. That list isn’t run by one company: about ten directory authorities (independent servers, run by different people and organisations) vote at regular intervals on the state of the network and produce a signed document — the consensus. The client downloads the consensus and picks its relays from it. Decentralising the list is part of the defence: there’s no single point to compromise or coerce to skew the network.
Onion services: when the address is the key
So far we’ve talked about exiting toward a normal site. But Tor can do the opposite too: publish a service reachable only inside Tor. That’s the onion service (the old «hidden service»), and its address is that long name ending in .onion.
In the current version (v3) the .onion address is 56 characters long and isn’t an arbitrary name: it’s the service’s public key (an ed25519 key) encoded in base32, with a couple of checksum and version bytes. An elegant consequence: the address authenticates itself. Whoever connects to that .onion is already verifying, mathematically, that they’re talking to the holder of that key — no certificates, no authority, no TLS on top. The name is the identity.
The mechanism, briefly: the service picks some relays as introduction points and publishes a signed descriptor (where and how to reach it); whoever wants in looks it up, then the two meet at a neutral rendezvous point. The detail that matters for the following howtos: both the service and the client only make outbound connections. Nobody opens a port, nobody exposes an IP. It’s precisely this outbound-only property that makes an onion service reachable even behind NAT, CGNAT or a firewall that lets nothing in.
«Speaking» addresses: vanity onions (and why the prefix is no guarantee)
You sometimes see onions that start with a sensible word — say, a data-breach service whose address begins with breachdb…. It’s no accident, but it isn’t what it seems either: it’s a vanity address. Since the address is the public key, you can’t choose it; but you can generate keys en masse until, by pure chance, one comes out whose address starts as desired. There are tools for it (for v3 the best known is mkp224o; for the old v2 it was scallion and shallot): they churn out millions of pairs per second and keep only the right one — the other 56 characters stay random, a real key.
Why almost nobody does it on long prefixes: the cost is exponential. The base32 alphabet has 32 symbols, so each extra forced character multiplies the work by about 32. An eight-letter prefix like breachdb means roughly 32⁸ ≈ 10¹² attempts — hours or days of GPU for a motivated operator; a fifteen-to-twenty-character prefix is, in practice, out of reach. The most famous case is Facebook: its historic facebookcorewwwi.onion (v2) came out half by luck and half by brute force — it looks hand-picked, but it was «just» fished out of billions of tries.
The moral is the same as self-authentication, and it matters: a whole address can’t be forged — choosing all 56 characters would mean finding someone else’s private key, i.e. breaking ed25519 — so vanity does not let you impersonate an existing service. But the prefix is no guarantee: an attacker can brute-force the same breachdb… start and fool anyone who only reads the first letters. That’s why a .onion must be checked in full, not at a glance: the complete key counts, not the look.
The «stealth» layer: the dark web you don’t browse
Here we bust the most widespread myth of all: installing Tor does not put you «in the dark web», just as having a browser doesn’t put you inside every website. What you reach with Tor alone is the cleartext layer of the dark web: onion services that answer anyone who knows the address. They aren’t indexed by normal engines and can’t be «scanned» (the address is a 256-bit key, you don’t guess it), but addresses circulate — wikis, lists, links — so in practice they’re found. That’s the «light» part, and it’s almost everything people call «dark web».
But there’s a layer below, and it’s no suggestion: client authorization (v3). The service publishes a descriptor encrypted for authorised clients only; without their own private key, a client doesn’t even receive the descriptor. Consequence: knowing the address isn’t enough. For anyone not on the list the service is indistinguishable from nothing — not a «password-protected door», but a door that doesn’t show itself at all. Tor historically called this mode stealth (in the old v2 onions there were two levels, basic and stealth); in v3 the official name is «client authorization», but the stealth property — invisible without an invite — remains, and that’s the point. What here we call deep dark web: the technical name is «client authorization» (or stealth), but the concept is exactly this — the dark web that doesn’t show itself without an invite.
It’s the difference almost nobody explains: the stealth layer isn’t something you «browse». Either you’re on the list (you have the key), or for you it doesn’t exist: no directory, no search engine that reaches it, no way to «stumble into» it. It’s the level used by whoever wants a service reachable only by those they chose — an organisation’s internal tools, reserved channels, sensitive research, and yes, also the systems that have an interest in not being found at all. In this series’ howtos it’s exactly the mechanism we use to publish a service that answers only who we say: you see it in action when Tor Browser asks you for the key before showing you anything.
Why normal DNS doesn’t resolve a .onion
If you try to resolve a .onion address with ordinary DNS, you get nothing: it’s not a domain «registered» somewhere. .onion is a reserved special-use domain (RFC 7686): resolvers, by spec, must not forward it to the public DNS. There’s no A record to return — and it would be useless anyway, because an onion has no IP.
«Resolution» happens inside Tor, differently: starting from the key in the address, the client looks up the service descriptor in a distributed hash table kept by the relays themselves (the HSDirs). That’s Tor’s «DNS»: no names to translate into IPs, but a key from which it derives where to meet the service. That’s why, on a normal system, opening a .onion requires a Tor client doing that lookup in place of the system resolver.
What it protects, and what it doesn’t (an honest threat model)
Tor is powerful, but it’s no magic wand: it’s worth being precise about what it guarantees.
- It protects location. Whoever receives the connection doesn’t see your IP, and you don’t see the service’s (in the onion case). For services that’s the key advantage: no public IP, no open port.
- It encrypts along the path. Between relays everything is encrypted. In the onion-to-onion case the traffic never leaves Tor: there’s no exit node that can read it.
- It’s not automatically anonymity. Hiding the IP isn’t enough: a normal browser leaks fingerprints (fingerprint, cookies, WebRTC) that identify you anyway. For real anonymity you need the Tor Browser, built for it.
- Toward normal sites, the exit sees the traffic. If you exit to a cleartext site (HTTP), the exit node can read it like any intermediary: Tor hides who you are, it doesn’t make an already-insecure protocol secure. (For onions this problem doesn’t exist: there’s no exit.)
- Your provider sees that you use Tor, not what. Traffic to the guards is recognisable as Tor. Where even that is a problem, there are bridges (unlisted relays, with disguises like obfs4) that mask the use of Tor — an advanced topic, only hinted at here.
In short: for this series’ howtos we’ll use Tor defensively — publishing and reaching our own services without exposing them, on an isolated lab and only with our own addresses. «Dark-web» anonymity is another matter, and where it’s relevant we’ll say so clearly.
From theory to practice: onionwatch
Once you understand how the dark web is built, the question that matters for defenders is one: «is anyone talking about me, down there?». It’s to answer this that at the Dojo I built onionwatch, a dark-web search engine designed defensively: it indexes Tor’s onion services — and I’m extending it to I2P, Freenet/Hyphanet and Lokinet — groups the mirrors, classifies sites with a reason, and above all searches by entity (an email of mine, a domain, a network range, a wallet) and puts under monitoring what interests me, alerting me when something new shows up. It’s not a public service: it’s a personal investigation tool, with three non-negotiable rules — defensive framing, disclosure discipline, never real addresses. The dark web, with a tool like this in hand, is no longer a dark place: it’s a network you can observe.
Reference: The Tor Project (project documentation). Special-use domain spec: RFC 7686. Freenet is today known as Hyphanet; the proportions between networks are estimates, not a census. Reference sheet of the «Tor / dark web» series.



