[tor-bugs] #7202 [Tor]: Implement ntor handshake or its successor

Tor Bug Tracker & Wiki blackhole at torproject.org
Thu Dec 13 21:03:27 UTC 2012


#7202: Implement ntor handshake or its successor
--------------------------------+-------------------------------------------
 Reporter:  karsten             |          Owner:                    
     Type:  project             |         Status:  needs_review      
 Priority:  normal              |      Milestone:  Tor: 0.2.4.x-final
Component:  Tor                 |        Version:                    
 Keywords:  SponsorZ tor-relay  |         Parent:                    
   Points:                      |   Actualpoints:                    
--------------------------------+-------------------------------------------

Comment(by nickm):

 Ian just gave me permission to post this from personal email:

 >There are three ways a point can be "bad":
 >
 >1. point at infinity
 >2. on the curve, but not in the prime-order subgroup
 >3. not on the curve at all

 >If each side generates their private keys with the low 3 bits set to 0,
 then after any exponentiation, the component outside the prime-order
 subgroup will vanish, as both the group and the twist group are of the
 form Z_k x Z_p for a small k that's either 4 or 8 (group or twist), and a
 large prime p.  So what's important is that the component in the prime
 subgroup is nontrivial.  Checking for all-0 bytes after the exponentiation
 will cover that.  So that deals with (1) and (2) above. [Well, it will
 allow points not in the subgroup as long as they have a non-zero component
 in the subgroup.  But that's OK.  It just means there are 4 or 8 ways to
 represent on the wire any particular point in the group.]
 >
 >The other question is what do you do if you get a point that's actually
 on the twist curve, and not on the main curve at all (3).  I'm pretty sure
 in that case (where one side is honest and generated points on the main
 curve, but the other side generated points on the twist), the dishonest
 party won't be able to generate the same secret as the honest party, as
 the honest party will take the dishonest party's public key to the power
 of something, yielding a point on the twist, while the dishonest party
 will get a public key on the main curve from the honest party, and won't
 be able to generate the corresponding point on the twist.  So I think you
 can just ignore this problem entirely, as the handshake will fail.

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


More information about the tor-bugs mailing list