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

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

#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 nickm):

 Reposting with permission an old message of Robert Ransom's about Valet
 Services, their drawbacks, and better living through cryptography:

 {{{
 The system described in section 3.2 of that paper does not allow a
 directory server to verify that a hidden service descriptor is being
 published to a descriptor index by a party which "owns" the index.  I
 see no way that the reverse-hash-chain technique described there could
 prevent an attacker from publishing a bogus descriptor with a targeted
 hidserv's descriptor index.  At best, if the hidserv "wins the race",
 the hash-chain would allow it to hold on to its descriptor index; at
 worst, the attacker could win the race and lock out the real hidserv.

 The only system I have come up with to hide a hidserv's identity key
 from the directory servers requires that the hidserv use a discrete-log
 cryptosystem for its identity key, and that the HS address contain
 enough of the identity key that a client can compute a scalar multiple
 of the identity key.  (For example, the identity key can be a point on
 an elliptic curve in Weierstrass form, and the HS address can be the
 point's x coordinate.)

 The system designer chooses a group, an element P of prime order p in
 that group, and a publicly computable one-way function h mapping
 bitstrings to integers in the interval [1, p-1].

 The HS chooses a secret key n and computes its public key nP; its
 descriptor index in time period t can be computed by any party which
 knows its public key as h(t | nP)*nP, but only the HS will know the
 discrete logarithm h(t | nP)*n of the descriptor index with base P.
 The HS can therefore compute an ECDSA signature, for example, which the
 directory server can verify using the descriptor index as a public key.

 > Also "Privacy-enhancing Technologies for Private Services", Karsten's
 > PhD dissertation, also available from the anonbib.
 > Also see Tor proposal
 > 121-hidden-service-authentication.txt

 I am aware of the current authentication mechanism for hidden services
 (which those documents describe), but it cannot hide the hidden
 service's identity key or name from the directory servers.

 }}}

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/8106#comment:6>
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