[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #8089 [Stegotorus]: Implement the handshake and key exchange as described in the paper



#8089: Implement the handshake and key exchange as described in the paper
------------------------+---------------------------------------------------
 Reporter:  vmon        |          Owner:  zwol
     Type:  defect      |         Status:  new 
 Priority:  critical    |      Milestone:      
Component:  Stegotorus  |        Version:      
 Keywords:              |         Parent:      
   Points:              |   Actualpoints:      
------------------------+---------------------------------------------------

Comment(by rransom):

 Replying to [comment:2 zwol]:
 > I like the sound of that; curve25519 has known-fast, known-constant-time
 implementations, which is decidedly not the case for OpenSSL's generic EC
 code, and also has been subject to considerably more cryptanalysis than
 MÃller's curve.
 >
 > However, could you please explain why it is necessary to make the
 modifications you describe?

 DJB specified that Curve25519 private keys are 32-byte strings with bits
 0, 1, 2, and 255 cleared and bit 254 set (see
 [http://cr.yp.to/papers.html#curve25519] page 5).  curve25519-donna
 enforces this in the same function which it exposes to perform the scalar
 multiplication.

 The server should choose a private key of the form DJB specifies.
 However, if clients choose keys with the low bits cleared, their public
 keys will always be in a prime-order subgroup of the curve or its twist;
 this distribution is easily distinguishable from uniform (less than half
 of the coordinate-field elements have prime order on the curve or twist).
 This is why curve25519-donna cannot be used without modification (as of
 the last time that I looked at the upstream version).


 There are two remaining issues -- remember that the high bit of the
 client's public key must be set to a uniform random bit (to remove an easy
 P=1/2 passive distinguisher), and the client's public key (including the
 padding bit) must be either included in the input to the KDF used to
 compute the symmetric key for the rest of the handshake message or covered
 by the MAC over the message (so that neither the curve point nor the
 padding bit can be modified by an active attacker).

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