Re: [tor-dev] [prop269] Further changes to the hybrid handshake proposal (and NTor)

["John M. Schanck" <jschanck@xxxxxxxxxxxx>]

Hi BU,

bustaoglu@xxxxxxxxxxxxxxxx wrote:
> Perhaps my question is related to Michaels question, but above removing A, X,
> Y and server ID leaves the possibility of a person-in-the-middle who by
> manipulating public keys (resend 2A, instead of A, 2X instead of X, 2Y instead
> of Y) can force two (non-matching) session share the same value denoted
> SECRET,
> Does including these public values in the value SALT take care of such
> "attacks".

For the version in which A, X, Y, and ID were all in SALT, see [1]
for a proof of security (tldr; yes putting these values in SALT instead
of in the extractor secret input field prevents the attack you mention).

The new version drops Y from SALT (A, X, and server ID are still
included), but that's irrelevant because we've stopped relying on SALT
to bind the derived keys to the transcript. In the new version the
server response includes a MAC computed over the entire transcript.
Non-matching sessions that compute the same session key will abort (with
overwhelming probability).

The proof from [1] goes through with a small modification to Game 5
of Lemma 4.3: show 'auth' is uniformly random; use PRF property to
replace HMAC keyed by 'auth' with a random function; mention that 
matching MAC tags imply matching sessions or, with negl. probability,
a collision in the random function.

> RFC5869 Section 3.3 To Skip or not to Skip addresses that part, but I can't
> conciliate your statement that the server can choose its public material in
> a way to bias the entropy extractor. Or is this simply the same problem viewed
> from a different angle?

RFC5869 Section 3.3 is about skipping the call to HKDF-Extract... we
don't do that. See [2] section 3 for more details on exactly what has
changed from ntor.

Cheers,
John

[1] https://www.degruyter.com/view/j/popets.2016.2016.issue-4/popets-2016-0037/popets-2016-0037.xml
[2] https://gitweb.torproject.org/torspec.git/tree/proposals/269-hybrid-handshake.txt
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev