A history of Tor: onion routing to today

The history of Tor, in short

The history of Tor begins in 1995 at the U.S. Naval Research Laboratory, a research lab of the U.S. Navy. David Goldschlag, Michael G. Reed and Paul Syverson built the first onion routing prototypes there. The Tor Project's own timeline says the question they asked was whether "there was a way to create internet connections that don't reveal who is talking to whom". The network people use today was deployed in October 2002, with its code released under a free and open software license. The Tor Project, Inc. was founded as a nonprofit in 2006.

Every date below comes from the Tor Project's published timeline, its release notes, or its own support pages. Where a claim is contested, such as who funds the work, the section says what the evidence is and where you can check it yourself.

What onion routing actually does

Onion routing separates two facts that the internet normally keeps together: who you are, and what you asked for. Your Tor client picks three relays and builds a circuit through them. It wraps your traffic in three layers of encryption, one layer per relay. Each relay peels one layer, learns only the address of the next hop, and passes the packet on. That layering is where the name comes from.

The first relay, called the guard, sees your IP address but not your destination. The last relay, the exit, sees your destination but not your IP address. The middle relay sees neither. No single relay holds both halves, and that is the entire security argument. It is also why the relays must be operated by unrelated people. If one organisation ran your guard and your exit, the separation is gone and the encryption bought you nothing.

The known weakness is traffic correlation. An observer who can watch both ends of a circuit at the same time can match the timing and the sizes of packets going in against packets coming out. Tor does not defend against an attacker who can watch the whole internet at once, and the 2004 design paper by Roger Dingledine, Nick Mathewson and Paul Syverson, "Tor: The Second-Generation Onion Router", said so in its threat model.

Why a private network would have been useless

This is the part short summaries skip, and it explains everything else on this page.

A military or intelligence organisation cannot get anonymity from a network that carries only its own traffic. Anonymity is a property of a crowd, not a property of a cipher. If every connection leaving the network belongs to one office, then an observer who sees a connection leave has already learned the answer. The encryption still works perfectly. The anonymity does not exist, because there is nobody to be confused with.

So the design had to be public and the traffic had to be mixed with other people's traffic. The code went out under a free software licence in October 2002, and anyone could run a relay. Journalists, activists, researchers, and ordinary people avoiding an advertising network all became the crowd that protects everyone else inside it. Dingledine and Mathewson set this argument out in 2006 in a paper called "Anonymity Loves Company: Usability and the Network Effect", presented at the Workshop on the Economics of Information Security. The conclusion is that the size and the variety of the user base is a security property of the system. It is not a marketing number.

From alpha code to a nonprofit

The Tor Project's timeline and its published papers record these steps:

• October 2002: the Tor network is deployed, with the code "under a free and open software license".
• End of 2003: the network runs on "about a dozen volunteer nodes, mostly in the U.S., plus one in Germany".
• 2004: Dingledine, Mathewson and Syverson publish the design paper "Tor: The Second-Generation Onion Router".
• 2004: the Electronic Frontier Foundation (EFF) begins funding the work on Tor.
• 2006: The Tor Project, Inc. is founded as a 501(c)(3) nonprofit to maintain development.
• 2007: work begins on bridges, because national firewalls have started blocking the public relay list.
• 2008: development of Tor Browser starts.

Two later dates matter for how the network is used now. The Tor Project's timeline places Tor's use during the Arab Spring in late 2010, protecting identity and reaching blocked sites. It also records the 2013 Snowden documents as the moment Tor's role became widely understood, and says the documents showed Tor had not been broken at that point. Neither event changed the protocol. Both changed who installed it.

Who pays for Tor, and how you check it

The Tor Project answers this on its own support pages: "The Tor Project is supported by a mix of government grants, private foundations, and individual donors." Government money is part of that, and it has been from the start. The supporters page names the U.S. Department of State alongside the Ford Foundation, the Open Technology Fund, Craig Newmark Philanthropies, and companies such as Brave, DuckDuckGo, Mullvad VPN and Fastly. Audited financials are published as blog posts, most recently covering the 2023 to 2024 financial year in December 2025. The project's stated position is that "talking openly about our sponsors and funding model is the best way to maintain trust with our community".

The useful question is not who paid. It is what money could buy. Tor is not a service you log into. It is a protocol specification, a client whose source you can read, and a network of relays operated by strangers. Someone who wanted a backdoor would have to put it in one of three places, and each one is checkable.

• In the source. The client is open source and the protocol is specified in public. Academic researchers publish attacks on Tor regularly, and they have every professional incentive to find a flaw first.
• In the binary. Tor Browser builds have been deterministic since August 2013, so an independent builder can rebuild a release and compare it byte for byte against the published download. A binary that does not match its source is visible without trusting the person who shipped it.
• In the relays. The Tor Project does not run the network. "The Tor network relies on volunteers to donate bandwidth", and the guards, middle relays, exits and bridges belong to thousands of unrelated operators. Compromising a funder does not compromise them.

The project's own statement is short: "Tor has no backdoors. The software is open source, its code can be independently audited, and every release is signed to protect against tampering." That sentence is worth something only because each clause names something you can go and verify.

There is a real caveat, and it is about priorities rather than integrity. Grant money decides which work happens first, so censorship circumvention has been funded more consistently than, for example, network performance. That is a fair criticism of the project. It is a different criticism from "the code is compromised", and you answer it by reading the financial reports rather than by trusting anyone's assurance.

Hidden services became onion services

An onion service is a server that never reveals its IP address. The client and the server each build their own circuit to a meeting point inside the network, so neither side learns the other's address. The address is not a name that a registry assigned to anyone. It is derived from the server's public key, which is why a .onion address looks like random characters.

The onion services timeline gives the releases:

• 8 April 2004: hidden services are first implemented, in Tor 0.0.6pre1.
• 21 September 2007: version 2 hidden services arrive, in Tor 0.2.0.7-alpha.
• 19 December 2016: version 3 development starts, in Tor 0.3.0.1-alpha.
• 9 January 2018: version 3 is released, in Tor 0.3.2.9.

The rename from "hidden services" to "onion services" happened gradually rather than on a single date, and the Tor Project's own documentation still uses both words. The old word described the wrong thing. Many onion sites are public, indexed and advertised; what is hidden is the server's location, not the site. The original name survives in the config file, which is a useful fossil. This is still how you declare one in torrc:

HiddenServiceDir /var/lib/tor/my_service/
HiddenServicePort 80 127.0.0.1:8080

The directory holds the service keys and a hostname file containing the address. The port line maps a port on the onion address to a local address on the same machine, so the web server can stay bound to 127.0.0.1 and never listen on a public interface at all. Version 3 is the default, so a service created with these two lines today gets a v3 address.

An onion address is also not a domain name. RFC 7686, published in October 2015, reserved .onion as a special-use domain name so that ordinary resolvers would stop leaking these lookups into the public DNS (domain name system). The rule it sets is blunt: "Authoritative servers MUST respond to queries for .onion with NXDOMAIN." Set that against how an ordinary domain name gets resolved and the difference is the whole point. A DNS name is assigned to you by a registry and looked up through servers you do not control. An onion address is a public key, so it authenticates itself and no lookup is needed.

Why old .onion addresses stopped working

The two address formats are not compatible, and the older one is switched off for good.

[
  {
    "version": "v2 (retired 2021)",
    "address_length_chars": 16,
    "service_key": "RSA-1024",
    "address_hash": "SHA-1, truncated to 80 bits"
  },
  {
    "version": "v3 (current)",
    "address_length_chars": 56,
    "service_key": "Ed25519",
    "address_hash": "SHA3-256"
  }
]

A v2 address was 16 characters because it carried only the first 80 bits of a SHA-1 hash of an RSA-1024 public key. A v3 address is 56 characters because it carries a complete Ed25519 public key, plus a checksum and a version byte. The v3 address is longer because it stopped truncating, so the address itself is now the full identity of the service.

The deprecation ran on an announced schedule:

• 15 September 2020, Tor 0.4.4.x: Tor starts warning operators and clients that v2 is deprecated.
• 15 July 2021, Tor 0.4.6.x: v2 support is removed from the code base.
• 15 October 2021: new stable client releases for every supported series disable v2.

The stated reason was cryptographic. "As humankind's understanding of math and cryptography evolved, the foundation of version 2 became fragile and at this point in time, unsafe." An 80-bit truncated SHA-1 hash and a 1024-bit RSA key were both below a sensible bar by 2021, and the address format left no room to change either one.

The consequence for a reader is simple, so it is worth stating plainly. Every 16 character .onion link published before 2021 is dead, permanently, and there is no redirect. A v2 address could not be upgraded, because the address was the old key. Operators had to create a new service and publish the new address through some channel their users already trusted.

Bridges and pluggable transports: censorship kept moving

The list of public relays is published on purpose, so a client can choose its own path instead of trusting one server to choose for it. That same published list is a ready-made blocklist for any country that wants to stop Tor. Work on bridges began in 2007. A bridge is a relay that is not in the public list. You request a small number of them by web or by email, and a censor cannot block addresses it cannot enumerate.

Blocking then moved from addresses to traffic shape. Deep packet inspection recognises the Tor protocol on the wire no matter which IP address it is going to. The answer was pluggable transports: a wrapper that changes what Tor traffic looks like without changing what it does. In current Tor Browser these ship as one binary named lyrebird, the successor to obfs4proxy, and the client side is three lines of torrc:

UseBridges 1
ClientTransportPlugin meek_lite,obfs4,snowflake,webtunnel exec [PATH]/lyrebird
Bridge obfs4 <IP ADDRESS>:<PORT> <FINGERPRINT> cert=<CERTIFICATE> iat-mode=0

Replace [PATH] with the directory holding the lyrebird binary, and take the whole Bridge line from the Tor Project's bridges site rather than typing it. Each transport solves a different blocking method:

• obfs4 makes the traffic look like nothing recognisable, with no protocol header a filter can match on. Tor's own advice is to try it first, because it is a randomising transport that works for most people.
• snowflake sends you through short-lived proxies run by volunteers inside ordinary web browsers, so the address you connect to keeps changing. It reached stable Tor Browser in version 10.5 on 6 July 2021.
• meek routes the connection through a large cloud provider, so the traffic appears to be going to that provider, and blocking it means blocking the provider too.
• webtunnel takes the opposite approach to obfs4. Rather than looking like nothing, it looks like an ordinary HTTPS connection to a web server, by "wrapping the payload connection into a WebSocket-like HTTPS connection". The Tor Project released it in stable Tor Browser on 12 March 2024, for networks that permit only a short list of protocols.

That sequence is the real shape of the last twenty years. Each new transport exists because a specific blocking technique started working, and the dates on those releases are a record of what censors were doing that year.

Tor is not a VPN, and a VPS is neither

Many people arrive at Tor after reading about VPNs, so it is worth being exact. A VPN (virtual private network) sends your traffic to one server run by one company, and that company sees your real address and your destination at the same moment. Tor sends your traffic through three relays run by different people, so no single one of them holds both facts. Those are different trust models with different failure modes. The difference between a VPS and a VPN covers where each one belongs.

If what you want is a private tunnel between machines you control, rather than anonymity inside a crowd, then you want a VPN you run yourself. You can self-host a WireGuard VPN on a VPS in about forty lines of config. That protects your traffic from the local network and from your internet provider. It gives you no anonymity from the company hosting the server, because you rented that server with your own payment details. The separate question of whether VPS hosting is safe is about a different threat again: who else can reach your box.

Running a relay is the other direction, and the network depends on it. Bridges, guards, middle relays and exits all need operators, and the Tor Project's relay guide is clear that "running a relay requires technical skill and commitment". Exits carry legal exposure, because other people's traffic leaves the internet under your IP address and your hosting provider will hear about it. Read that guide before you start one, not after.

FAQ

Was Tor built by the US government?

Onion routing started at the U.S. Naval Research Laboratory in 1995, where David Goldschlag, Michael G. Reed and Paul Syverson built the first prototypes. Tor itself was the next generation design, started around 2001 and 2002 by Roger Dingledine, Nick Mathewson and Paul Syverson, and the network was deployed in October 2002 under a free software licence. The Tor Project, Inc. has been an independent 501(c)(3) nonprofit since 2006. The government origin is real, and it is also the reason the network had to be opened to everyone: a network carrying one organisation's traffic gives that organisation no anonymity, because every connection leaving it identifies the sender by the fact of using it.

Does government funding mean Tor has a backdoor?

The Tor Project's answer is "Tor has no backdoors. The software is open source, its code can be independently audited, and every release is signed to protect against tampering." What makes that testable rather than a promise is the structure around it. The protocol is specified in public, Tor Browser builds are deterministic so an independent builder can rebuild a release and compare it against the published binary, and the relays are operated by volunteers rather than by any funder. Funding does influence which work gets done first, and the audited financial reports on the Tor blog show where the money came from. That is a question about priorities, not about the code.

Why did my old .onion address stop working?

It was a version 2 address, and v2 onion services were retired in 2021. Tor began warning about it on 15 September 2020, removed v2 from the code base in Tor 0.4.6.x on 15 July 2021, and disabled it in stable releases on 15 October 2021. A v2 address is 16 characters before .onion and a v3 address is 56. There is no redirect and no upgrade path, because the address was derived from the old key, so the operator had to create a new service and publish the new address.

Is Tor the same as a VPN?

No. A VPN sends your traffic to one server operated by one company, and that company can see your real IP address and your destination together. Tor sends traffic through three relays operated by different people, so the first relay sees your address without your destination and the last sees your destination without your address. Tor is slower, and it is built for anonymity against an observer who is not watching the whole internet. A VPN is faster, and it is built for privacy from your local network and your internet provider.

What is a pluggable transport, and do I need one?

A pluggable transport is a wrapper that changes what Tor traffic looks like on the wire without changing how Tor works, so a filter that recognises the Tor protocol cannot match on it. You need one only if plain Tor fails to connect, which usually means your network or country is blocking it. Tor Browser ships obfs4, snowflake, meek and webtunnel in a single binary called lyrebird. Start with obfs4, because it is a randomising transport that works for most people, and try webtunnel or snowflake if that connection never completes.