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

[Michael Rogers]

On 14/10/16 22:45, isis agora lovecruft wrote:
>  1. [NTOR] Inputs to HKDF-extract(SALT, SECRET) which are not secret
>     (e.g. server identity ID, and public keys A, X, Y) are now removed from
>     SECRET and instead placed in the SALT.
> 
>     Reasoning: *Only* secret data should be placed into the HKDF extractor,
>     and public data should not be mixed into whatever entropic material is
>     used for key generation.  This eliminates a theoretical attack in which
>     the server chooses its public material in such a way as to bias the
>     entropy extraction.  This isn't reasonably assumed to be possible in a
>     "hash functions aren't probablistically pineapple slicers" world.
> 
>     Previously, and also in NTor, we were adding the transcript of the
>     handshake(s) and other public material (e.g. ID, A, X, Y, PROTOID)
>     directly into the secret portion of an HMAC call, the output of which is
>     eventually used to derive the key material.  The SALT for HKDF (as
>     specified in RFC5869) can be anything, even a static string, but if we're
>     going to be adding transcript material into the handshake, it shouldn't be
>     in the entropy extraction phrase.

Hi Isis,

Sorry if this is a really stupid question, but there's something I've
never fully understood about how RFC 5869 describes the requirements for
the HKDF salt. Section 3.4 says:

   While there is no need to keep the salt secret, and the
   same salt value can be used with multiple IKM values, it is assumed
   that salt values are independent of the input keying material.  In
   particular, an application needs to make sure that salt values are
   not chosen or manipulated by an attacker.  As an example, consider
   the case (as in IKE) where the salt is derived from nonces supplied
   by the parties in a key exchange protocol.  Before the protocol can
   use such salt to derive keys, it needs to make sure that these nonces
   are authenticated as coming from the legitimate parties rather than
   selected by the attacker (in IKE, for example this authentication is
   an integral part of the authenticated Diffie-Hellman exchange).

As far as I can tell, the assumption in this example is that the
attacker is not the other party in the key exchange - otherwise
authenticating the nonces wouldn't tell us whether they were safe to
include in the salt.

If we're concerned with the server choosing its public material in such
a way as to bias the entropy extraction, does that mean that in this
case, the attacker is the server, and therefore the server's public
material shouldn't be included in the salt?

Again, probably just a failure on my part to understand the context, but
I thought I should ask just in case.

Cheers,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x9FC527CC.asc
Type: application/pgp-keys
Size: 4660 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20161017/b7ff4de6/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20161017/b7ff4de6/attachment.sig>