[tor-bugs] #8106 [Tor]: Make .onion addresses harder to harvest by directory servers

[Tor Bug Tracker & Wiki]

#8106: Make .onion addresses harder to harvest by directory servers
-----------------------------+----------------------------------------------
 Reporter:  asn              |          Owner:                    
     Type:  defect           |         Status:  new               
 Priority:  major            |      Milestone:  Tor: 0.2.5.x-final
Component:  Tor              |        Version:                    
 Keywords:  SponsorZ tor-hs  |         Parent:                    
   Points:                   |   Actualpoints:                    
-----------------------------+----------------------------------------------

Comment(by hyperelliptic):

 Replying to [comment:16 rransom]:
 > Also, the blinded base point is a function of the non-blinded public
 key.
 I understand, that's why I said that the clients will notice the attacker,
 but the server cannot check this (without knowing A -- and the whole point
 of this scheme is that the server should not know A). There is also no way
 that the server can verify that B and the other point have been multiplied
 by the same scalar -- again, that's a feature, otherwise you'd be back to
 enumeration attacks, so don't try using pairing-friendly curves on this.

 My understanding is that the nonce will be time dependent, so clients know
 the nonce and know the public key of the hidden service and everybody
 knows B. So, they can compute HB(nonce, B, pub.A) and the updated key
 parameters. I assume that they then ask the server for the information on
 Aprime = scalarmult(blindingExponent, pub.A), right? If the server stores
 the encrypted routing information under Aprime then I can override this --
 with a differnt Bprime, but there is no way to say which one is right; you
 cannot take the first one either, otherwise at least insiders knowing A
 can compute the next Aprime just a tad faster and submit that along with a
 wrong Bprime.

 Note that you need 2 different verification equations: one for the server
 (which does not know A and the nonce) and one for clients who first
 recompute Aprime and then check that the world matches, i.e. the
 verification needs 2 steps.

 I realize that you can bootstrap from this by including Bprime in the
 storage location so that the real data and the attack data get written to
 different places, but then you suddendly have twice the length.

 Could you describe what worried you about the version in which the
 basepoint does not vary?

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/8106#comment:17>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online