On Tue, May 12, 2020 at 12:31 PM Dan Brown <danibr...@blackberry.com> wrote:
> Hi Hugo, > > > > Some curious molehill questions. Please take with a grain of salt. > > > > In short, does HKDF-Extract suffer from related-salt and repeated-IKM? > > > > To elaborate: > > > > Phillip raises a good point below about HMAC suffering from key-extension > (by zero bytes). You are right that this is not a MAC attack, the main > intended use of HMAC, but now the scope of HMAC has expanded to non-MAC > purposes. > > > > Surely HMAC has good PRF properties, so non-MAC applications make sense. > For what little it’s worth, I had just presumed that HKDF always used HMAC > with the a strong secret key, like a good PRF should. (I failed to verify > this, though.) > > > > But Phillip seems to want to use structured HMAC keys (i.e. not uniformly > distributed keys), specifically the salts in HKDF-Extract, I presume. > Under my presumption, this would not be best practice (using structure or > related keys). > > > > So, I went to the HKDF RFC, basically expecting to find this clearly > disallowed. Re-reading the RFC, it was unclear to me what kind of salt was > allowed. (The eprint might be clearer, but it is longer to find this > needle.) Would it (dis)allow the structured salts Phillip described? > The HMAC RFC is from 1997. While we have revised the spec to add new digest algorithms, we have never revised the security considerations. I think we should take the opportunity to level up to our current best practices rather than relying on the old. Back in 1997 we were still using DES as the blockcipher but very few folk were talking about the fact that we should be considering birthday attacks and limiting the amount of cipherstream generated under a particular key. We do consider that type of issue today. The concern I have is not the number of keys generated from a given IKM or PRK so much as the amount of data those keys are used to encrypt. If I have a log file with 1 million entries of 120 bytes, am I worse off by generating 1 million keys from the same IKM or by generating one key and using different IVs? The second is closer to customary practice but only because we are considering the KDF as being a completely separate thing from the block cipher key schedule. Since I cannot do a key agreement for every log entry, there will be related keys or repeated keys. The question is which we prefer. Another application of the same approach is to encrypt a live video stream and its associated data frame by frame with the intention of retaining random access, fast forward etc. capabilities. I cannot perform a key exchange per frame. But I can do a KDF per frame. Regarding the salt input to the KDF as being a substitute for the IV gives me the performance and flexibility I need without increasing the amount of data per entry. I just generate an IV along with my session key. The whole point of this approach is to construct a mechanism that allows me to be very sure that every piece of encrypted data is encrypted under a different key. It is really hard to screw up without it being apparent. So in summary: * Consider the NIST certification process to be an opportunity, not a burden. * We should revise the RFCs for HMAC and KDF. HMAC in particular needs proper security considerations. * We should look at the security of both the individual components and the composition of the components in a system and require that both be sound as opposed to allowing either. * We should propose a simple, backwards compatible means of protecting against the zero key padding issue on HMAC. One approach is simply appending a non zero byte to the key. 0x50 is what I plan to use for my HMAC variant unless someone has a better idea.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
