[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):

 Hi, this is Tanja Lange
 Replying to [comment:13 rransom]:
 > Replying to [comment:12 asn]:
 > > I called it extra because the hash in the vanilla verification
 equation is `H(R,A,M)` while yours has 4 parameters: `H(R, HB(nonce, B,
 A)*B, HB(nonce, B, A)*A, M)`
 >
 > In Ed25519, the public key is `A`.  In my blinded-public-key variant of
 Ed25519, the blinded public key is `(HB(nonce, B, A)*B, HB(nonce, B,
 A)*A)`.  Since Ed25519 uses `H(R, (public key), M)` as its message hash,
 the obvious message hash to use for a blinded-public-key version was `H(R,
 (blinded public key), M)`.
 >
 I'm a bit puzzled by the basepoint updating etc. Could you state what your
 definition of S is (other than: it's the S that makes this work). In
 general you want to avoid inversions modulo the group order.

 I also doubt that basepoint blinding is a good idea: I understood the idea
 of this scheme to be that the server can "verify" signatures under the
 updated public keys and ensure that no party can override another parties
 data (unless by chance they hit the same daily public key or one party
 breaks the DLP). However, if I let an attacker choose the basepoint then
 he can sabotage the system by choosing the public key the same as mine
 (i.e. overriding my data) and computing a basepoint and matching secret
 key to have the signature verify on the server side. Of course this would
 be caught by the clients, because the signature is not valid under what
 should be today's basepoint so it "only" affects availability but that's
 not good. You cannot give the functionality to compute today's basepoint
 to the server (if you want to hide A), so I don't know how to bootstrap
 from this. I don't have a similar concern with the original scheme posted
 in the email.

 If you want proofs then of course it's necessary to come up with a simple
 cryptographic assumption that this can boil down to -- but it makes sense
 to define the scheme first (and rule out simple attacks).

 Some commments on the earlier post:
 I don't see what the trouble with the factor 8 on all sides would be -
 other than 3 extra doublings.

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