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
Attachment:
0x9FC527CC.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev