[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 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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs