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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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 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.

 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.)

 (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â).)

 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.

 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.

 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.

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