Re: [tor-bugs] #18191 [Core Tor/Tor]: .onion name collision

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#18191: .onion name collision
--------------------------+--------------------------
 Reporter:  cypherpunks   |          Owner:
     Type:  defect        |         Status:  reopened
 Priority:  Very High     |      Milestone:
Component:  Core Tor/Tor  |        Version:
 Severity:  Critical      |     Resolution:
 Keywords:                |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:
--------------------------+--------------------------

Comment (by teor):

 Replying to [comment:4 cypherpunks]:
 > > 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 hidden services. **
 >
 > Why not, is the public key cached somewhere? Does there take some kind
 of decentralized registration of hidden services take place?

 I think the quote is subtly wrong in at least two ways. And since you
 didn't source it, that makes it hard for me to work out if the context
 explains it better. But I'm not going to follow it up, as we're working on
 a replacement right now.

 Here's the first mistake:
 The address is a hash of the public key. The public key is included in the
 hidden service descriptor. The public key matches the private key for the
 hidden service. But the public key is looked up by address. So a limited
 form of impersonation is possible in clients without cached descriptors.

 Here's the second mistake:
 A birthday attack only gives you a collision (one match in the output) not
 a second preimage (the input that produces a specific output match).

 > I find this highly unlikely because Hidden services can be created
 instantly and thousands are created each month (?)
 > In order to cache or register every public key you'd need quite some
 disk space.

 Indeed. You should read up on the distributed hidden service hash ring.
 https://gitweb.torproject.org/torspec.git/tree/rend-spec.txt

 > Please don't just close this without proper explanation!

 You may need to do some further reading to understand the explanations
 that we're giving you.

 > And simply use (way) more than 80 bits, and a different hash algorithm.

 Yes, here is the proposal to do just that:
 https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-
 ng.txt
 We're implementing it right now.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/18191#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs