[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 nickm):

 Replying to [comment:13 mikeperry]:
 > What is the tor-dev post discussing the checks on X for this curve?
 (There are at least 4 or 5 threads on circuit handshakes with different
 subjects, and the only thread I see with ntor in the subject is not
 talking about ntor.)

 Try "New Paper by Goldberg, Stebila, and [UO]staoglu ...".  (I misspelled
 Berkant's name in the subject originally.)

 In particular see Ian's messages on that thread.

 I'll ask Ian if he has a good writeup in one place for the spec; if
 anybody else has one, that would be keen too.

 > Either way, I still think the source, the spec or both should explain
 why we can omit the checks on X and/or Y for our curve choice, and perhaps
 cite the curve25519 paper pages or relevant material if the answer is
 buried in there. In every other DH-esque protocol, omitting checks that
 g^q = 1 and identity checks on keys is asking for critical vulnerability..
 I do *not* think the new comment does this. It only says "beware of
 dragons on other curves!". It doesn't say why our curve is dragon-proof by
 default.

 Errr... it *does* check to see whether g^pq == the identity element.  (Or
 rather whether Gpq == the identity element.)  That's what all of those
 tor_memeq(x, "\x00\x00\x00\...") things in af175dbe07d3fd71 are.  If one
 of the inputs is the identity element, then the output will be too.  Are
 you looking at the *final* version of the code, or at intermediate
 versions?  It might be a good idea to make a local copy of the branch and
 do "git rebase -i --autosquash" on it.

 *ALSO*, I'm pretty sure that attacks substituting in the identity element
 aren't what we're worried about here.  Suppose that an adversary tries to
 do that, and we don't check for 0.  So alice sends X, and the adversary
 substitutes X'==0.

 Now Bob computes Xb == 0 and Xy==0, so his secret_input == 0, 0, ID, B, 0,
 Y, PROTOID. His verify is H_verify(secret_input). His auth_input is
 verify, ID, B, Y, 0, PROTOID, "Server". He sends back Y and H(auth_input).

 Now the adversary is stuck!  Alice is going to reject any modified message
 unless the adversary can provide an H(auth_input) based on Xb, not 0b.
 But the adversary doesn't know b--that's Bob's private key.  So the attack
 fails.

 If the adversary tries replacing Y with 0 but not X with 0, then the
 adversary still won't be able to make the client think the handshake
 worked.

 So whatever attacks we're worried about here, the "substitute the identity
 element" attack isn't one.

 > Speaking of g^q == 1 check, I assume we also know this is true for our
 g=9 choice because of some deep curve25519 magic used to construct the
 subgroup?

 It's not our choice, it's djb's choice. His paper has more info.

 > Forgive me for still thinking of this problem in terms of Z_p, but if we
 write our protocols such that only people who already understand both ECC
 and the deep magic of our specific curve choice can verify their
 correctness, we're begging for mistakes to slip through unnoticed due to
 lack of eyeballs.

 I sympathize; like I've said, I'm asking Ian if he has a writeup-for-
 regular-folks sitting around I could use.

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