[tor-bugs] #18191 [Core Tor/Tor]: .onion name collision
Tor Bug Tracker & Wiki
blackhole at torproject.org
Mon Aug 15 00:32:38 UTC 2016
#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
More information about the tor-bugs
mailing list