Onion Services

Led by George and dgoulet.



  • New crypto (replace RSA-1024, SHA-1, etc. with EDdjb, SHA-3, and other modern crypto)
  • No onion enumeration attacks
  • Encrypted descriptors
  • New onion addresses (16 chars -> 54 chars)
  • Harder to target specific hidden services (e.g. malicious HSDir attack)
  • Better client auth

o Use asymmetric crypto instead of symmetric crypto

  • More reliable because there is a longer window for updating everyone in the network about HS's rotated descriptors
  • Hidden services will be able to store their keys offline (better compromise protection)

How are you going to transition from old-style .onion addresses to new ones?

  1. Plan to maintain compatibility with old .onion addresses for a while
  2. Eventually, everyone will have to transition to new .onion addresses. No fancy plan for transitioning, they should just get a new-style .onion address and advertise it out of band.


  1. Shared Random Numbers (prop250 -> srv-spec.txt). *Done and merged: 0.2.9.*
  2. HSDir: code that generates descriptors, caches them, stores them, etc. *Done and merged: 0.3.0.*
  3. Relay side code: new Introduction Points and Rendezvous Points. *Done and merged: 0.3.0.*
  4. Server-side implementation (create hidden service, advertise it, accept connections, etc.). *85% done, goal: very early 0.3.2.*
  5. Client-side code: downloading descriptors, establishing rendezvous points, sending INTRO cells. *Not really started, ~15% done, goal: very early 0.3.2.*


  1. Expect to create 0.3.2 branch sometime in July.
  2. Release 0.3.1 in August.
  3. Release sometime in mid-September, probably will have a (buggy, initial) release of the next generation hidden services.
  4. Goal is to work out bugs for a stable release in 0.3.2 in mid-December.

Current hidden service protocol is v2. Next-generation hidden services are v3.

How does one set up a new Tor hidden service? In torrc:

  • HiddenServiceVersion. Currently available but no one uses it because it only has one default value: 2. Once v3 is availabe, you can set this to 3 to use next-generatoin hidden services.

o Can run both v2 and v3 hidden services on the same server at the

same time. Hidden service configuration is already naturally organized into per-service "blocks" in the torrc config.

Extras (the "flavorful sauce") for v3:

  • Offline keys
  • Control port


+ This will be late 0.3.2 or a later release, unless somene

volunteers to help write the spec and implement it.

  • Client authorization

o Appendix E in Prop224 has a rough idea of how this will work.

Dying in v3:

  • Tor2Web

o No plan to include special support for Tor2Web in the

next-generation hidden services code

o David recommends his project OnionGate as an alternative (that

does not require special support from Tor)

Explanation of shared randomness protocol.

What is the shared random value used for? Deterministic HSDir hash ring computation allows attackers to brute force identity keys for HSDir relays that can target specific hidden services, allowing them to track client metrics and/or DOS the hidden services. Tor Project is actually detecting HSDirs performing this attack today (and kicking them from the network when this behavior is detected). Shared random value is used to prevent positions in the hash rings from being computable far enough in advance to generate malicious identity keys and create malicious HSDirs.

How do you defend against attacks on the shared consensus? DocTor includes checks that compare all of the advertised values from each dirauth with the values that were received for that dirauth by all the other dirauths. To enable this auditing, each dirauth gossips all the values they receive from each other dirauth in the consensus.

How can we make the new (brutally long) onion addresses usable?

  • Idea: Name System API.
    • Map pseudo-TLDs to different name resolution strategies. For example:
      • .scallion → NameCoin
      • .hosts → hosts file
      • .gns → GNUNet naming system
  • Idea: "hack" HTTPS everywhere to include related .onions.
    • New pseudo-TLD ".everywhere"
    • Remap known DNS -> .onion (e.g. → facebookcorewwwi.onion)
  • Smart bookmarks/petname system
  • "Let's Onion". Use Let's Encrypt to issue TLS certificates that associate a domain name with an .onion address, which may be identified and used by onion-aware clients.
  • DNS → TXT records .onion (similar).

These are just proposals, there are no specific plans to implement one or the other of these proposals. They hope to make it GSoC project.

Explanation of blinded signing keys in v3 HS protocol (2 math 2 type).

Current work does /not /attempt to address:

  • Circuit fingerprinting
  • Guard discovery attacks

These attacks are out of scope for the current proposal and are covered by various other proposals.

Explanation of guard discovery attacks (2 diagram 2 type).

Last modified 2 years ago Last modified on Mar 28, 2017, 9:36:12 PM