Hi BU,
bustaoglu@cryptolounge.net 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/p... [2] https://gitweb.torproject.org/torspec.git/tree/proposals/269-hybrid-handshak...