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

[Tor Bug Tracker & Wiki]

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

 Replying to [comment:27 rransom]:
 > The server looks up B in a constant-time map in order to prevent an
 attacker who is monitoring the server for side-channel leaks ''and cannot
 read a client's `CREATE` cell'' from determining whether the client is
 using the server's current or previous ntor public key.  This attack is
 not especially plausible or likely, but defending against it is easy
 enough, and it's much better than Tor's usual practice of not trying to
 defend against any side-channel attacks.

 Okay.

 > Line 21 is almost entirely correct; the only incorrect statement in it
 is that things will break somehow if X is not included in the hash
 function's input.  ntor is secure even if none of the public keys (long-
 term and ephemeral) are passed as inputs to the KDF, because if the server
 properly generates B and the client properly generates X, `x*B` is not
 known to the attacker.  (A malicious server or client can completely break
 the protocol's security without generating B or X improperly by giving
 their secret keys to an attacker.)

 Okay, thanks.

 > (Elliptic-curve groups are usually written ‘additively’ -- the group
 operation is written as addition, and ‘exponentiation’ is written as
 multiplication (and referred to as ‘scalar multiplication’).)

 Okay; I take it the need to refer to the addition/multiplication
 operations in the underlying field the curve is defined over distinctly
 does not create ambiguity in practice?

 > The ‘point at infinity’ on a Montgomery-form elliptic curve is the
 group's identity element.  There is absolutely no reason to check whether
 any public key or shared secret used in ntor is the point at infinity;
 read section 3 of the Curve25519 paper for why.

 Hmmm, okay.  I'm not sure why the 'on a Montgomery-form elliptic curve'
 qualifier appears; does it denote a particular way of representing points
 (and so the group operation should not depend on it), or a particular
 subset of curves?  Well, you seem to have much more background on this
 than I do, so I'll take your word for it and go read up some more and
 await enlightenment.
 >
 > In Tor's current/old circuit-extension protocol, the server publishes an
 encryption public key (‘onion key’) `K` in its descriptor, the client
 sends `E_K(g^x)`, the server replies with `g^y`, and both parties compute
 and use `g^xy` as their shared secret key.  The ‘2007 DH bug’ was that
 clients would accept 0 or 1 or p-1 or p or p+1 as `g^y`, because they had
 no way to verify that `g^y` was sent by the server other than by assuming
 that `(g^y)^x` would be unknown to the attacker.

 Okay, thanks.

 > A good PRNG has two states: insufficiently seeded (i.e. not yet safe to
 use for any purpose), and sufficiently seeded that it can produce as many
 random bits as its caller needs.  If your PRNG can be attacked by
 ‘consuming entropy’ from it, it is either insufficiently seeded or bad.
 If your PRNG is bad, it should be thrown away and replaced.

 Hmm.

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