wiki:doc/HiddenServiceNames

Version 22 (modified by traumschule, 2 months ago) (diff)

add info on v3 naming scheme

Why are v3 onions better?

Since Tor 0.3.2 and Tor Browser 7.5.a5 56bit long v3 onion addresses are supported and should be used instead. In short SHA1/DH/RSA1024 has been replaced with SHA3/ed25519/curve25519 (non-NIST curves), less information is leaked to directory servers, the directory protocol has a smaller surface for targeted attacks and 56 characters long onion addresses improve security against impersonation (for details see the v3 spec). Also How to setup a v3 onion service

How are .onion names created?

If you decide to run a onion service Tor generates an RSA-1024 keypair. The .onion name is computed as follows: first the SHA1 hash of the DER-encoded ASN.1 public key is calculated. Afterwards the first half of the hash is encoded to Base32 and the suffix ".onion" is added. Therefore .onion names can only contain the digits 2-7 and the letters a-z and are exactly 16 characters long.

For v3 the address is the long term master identity key. The entire key is Base 32 encoded, including a version byte and a checksum, and then appending the string ".onion" at the end. The result is a 56-character domain name.

Why are .onion names created that way?

The reason for using cryptic fingerprints instead of human-readable names is described in Zooko's Distnames: they are self-authenticating. If a client wants to connect to a onion service he asks the directory services for the .onion name's service descriptor which includes its public key. If the hash of the public key matches the .onion name, the client can be sure it will encrypt data for the right onion service.

"Zooko's Triangle" which is discussed in Stiegler's Petname Systems argues that names cannot be global, secure, and memorable at the same time. This means while being unique and secure, .onion names have the disadvantage that they cannot be not meaningful to humans.

Can i obtain a complete list of .onion names?

No. There is no central authority nor repository of .onion space.

What about collisions in the hash function?

The output of SHA1 has a length of 160 bit. To make handling the URLs more convenient we only use the first half of the hash, so 80 bit remain. Taking advantage of the Birthday Attack, entropy can be reduced to 40 bit. That's why collisions could be found with moderate means. This is not a problem for Tor since all an attacker might be able to do is create two different public keys that match the same .onion name. He would not be able to impersonate already existing onion services.

For SHA-3 only theoretical preimage attacks are known so far.

Which attacks remain concerning the naming scheme?

Names can be mimicked as described in Plasmoid's Fuzzy Fingerprints. Here is how it works: many people cannot remember the whole .onion hash, nor did they write it down somewhere. Therefore they only check the first and last couple of characters and then assume it is alright.

This issue has been first exploited for SSH fingerprints but can be adopted to Tor onion services easily. E.g. the first seven characters of a specific .onion name can be computed within a day on a standard PC using programs like Shallot or Scallion. Imagine an attacker creates a .onion name that looks similar to the .onion of a different onion service and replaces its hyperlink on the onion Wiki. How long would it take until someone would recognize?

These days most people know that it is important to check the correctness of SSH or GPG fingerprints, but there is not much awareness for .onion names yet. As a counter-measure you should bookmark onion services that need to be trusted instead of just following hyperlinks everyone can edit.

With v3 a hash-based checksum of two bytes (16 bits) is used. This means "that after 256 typos we will have 50% probability to miss an error" (tor-dev).