Re: [tor-dev] Another key exchange algorithm for extending circuits: alternative to ntor?

[Robert Ransom <rransom.8774@xxxxxxxxx>]

On 8/10/12, Robert Ransom <rransom.8774@xxxxxxxxx> wrote:
> On 8/8/12, Nick Mathewson <nickm@xxxxxxxxxxxxx> wrote:
>
>> http://www.infsec.cs.uni-saarland.de/~mohammadi/owake.html
>
> Also, where does this paper specify that the participants must check
> that public-key group elements are not equal to the identity element?
> That's rather important, as Tor's relay protocol is likely to break if
> an attacker can force a server to open additional circuits to an
> attacker using the same key material that a legitimate client's
> circuit has.

It occurred to me later that the server would know that H(g^(x_1*b +
x_2*y), g^y) is âfreshâ, and that the client would know that the
server would not use H(g^(x_1*b + x_2*y), g^(x_1), g^(x_2), g^y) as a
key with a party that presented some public key other than (g^(x_1),
g^(x_2)) to it, so I checked the paper for *that* defense against
tampering and found it in Figure 4.  (That is a critical detail of
this protocol, and not necessary to protect honest clients against key
reuse in ntor, so it should have been included in the specifications
of the protocol in Figures 3 and 5 and the first two paragraphs of
section 3.1.  Hopefully the authors will fix that too when they revise
their paper.)

I don't see any way to attack âAceâ with the client and server
ephemeral public keys included in the data passed to the KDF.


Robert Ransom
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev