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

 Replying to [comment:18 asn]:
 > Hey Robert,
 >
 > I talked with hyperelliptic today and she explained me her concerns of
 comment:17.

 None of those concerns are legitimate.

 > I'm just bumping this thread -- in case you missed the last comment or
 forgot about it -- because now I'm also wondering about the leak in the
 version where only the public key is blinded.

 I have told you three times now -- twice on this ticket, and another time
 in a semi-private discussion -- why my cryptosystem is as secure as
 Ed25519.  This is the last time that I will explain it to you.

 As you know, in all ElGamal-like discrete-logarithm-based signature
 schemes, each signature discloses a linear equation relating the long-term
 signing secret key to the per-message secret key.  Because of this
 information leak, a signature scheme which is secure when used with
 independent, identically distributed long-term signing secret keys may not
 be secure when a signer uses multiple long-term secret keys which are
 related by publicly known equations.  (Forgery remains as hard as
 recovering one of the secret keys, even when they are related.)

 My original idea was to use an existing signature scheme with multiple
 related secret keys.  Since you and Nick claim to be too afraid of ânewâ
 cryptographic primitives to consider using one in Tor, this would have
 required an easy-to-understand security argument, and I didn't expect it
 to have one.

 In my revised cryptosystem, each signature discloses the same linear
 equation involving the hidden service's long-term signing secret key that
 an Ed25519 signature using a slightly different hash function would.
 Thus, this cryptosystem is provably as secure as Ed25519, ''and'' the
 proof is so simple that anyone who had read the Ed25519 paper would
 understand it.

 Because my goal was to find a cryptosystem which would provide the
 security properties which a new hidden service protocol would require, I
 quit looking for a security argument for my original idea once I had found
 an alternative with such a simple proof of security.  I don't know why you
 have put so much effort into finding a broken scheme to use instead.

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