[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #7202 [Tor]: Implement ntor handshake or its successor
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs