Re: [Cfrg] [TLS] NIST crypto group and HKDF (and therefore TLS 1.3)

["Dang, Quynh H. (Fed)" <[e-mail]>]

Hi Uri,

Let me elaborate more on what I said by red text inside the message below.


________________________________
From: Blumenthal, Uri - 0553 - MITLL
Sent: Thursday, May 14, 2020 11:00 AM
To: Hugo Krawczyk; Dang, Quynh H. (Fed)
Cc: [e-mail]
Subject: Re: [Cfrg] [TLS] NIST crypto group and HKDF (and therefore TLS 1.3)


When the IKM is longer than 1 block, it gets hashed iteratively by the compression function in Merkle-Damgard fashion (the hash function). Then, this hashed result is padded to become a full block, then Xor with opad and ipad (making input blocks are "independent"/different blocks/keys.  One of these Xored values is hashed with the salt, then its result and the other Xored value get hashed one more time by the iterative MD-hash function.



I dont understand why any extraction property that you get from the traditional extraction gets lost by this alternative method.



The only way I know to justify this step in general is to assume the underlying hash function is a RO which is general is not, due to extension attacks.



Can you please explain: what is the significance of extension attacks in this context?

KDF is not a MAC. And while it’s nice to have a construction as generic as possible – sometimes it helps to narrow the applicability scope, because the generic version may be too limiting for that specific use case.



This would make the analysis fully dependent on RO while the analysis of HKDF can use less stringent modeling depending on particular cases.



Thank you. One conclusion I draw form this is – since extension attacks do not seem to apply/matter for the Key Derivation, it is reasonably safe to model the entire hash function as RO. Therefore, the proposed option appears to be safe.



For me, it is less important to stay generic than to be able to employ currently-available commercial HSM. For that use case, modeling hash function (even SHA-2) as RO seems OK.



I don't know how you do that if the only input to the function is an initial hash value of the IKM.



When the IKM is not more than an input block, then each of  the 2 Xored values gets processed by 1 compression function call which is modeled as a RO. I dont understand why this alternative method losses some extraction property from the traditional extraction function.

In this situation, for the final hash function call, the first input block to the compression function is (K0 Xor opad) is treated as a secret input block.  The next (also final) input block to the compression function: (H(K0 Xor ipad || salt) || fixed padding), where fixed padding is half input block (by the hash function) and H(K0 Xor ipad || salt) is a secret half of the input block.  So, the IV to this compression when processing the final hash input block is a secret value and its data input is half secret and half fixed known value. So, a collision attack using length extension does not apply here since half of the input block is unknown. And, it would not make any sense to do length extension attack on the fixed padding (the attacker is interested in finding a MAC for a message which has the prefix being the message (the salt in this case).


One could argue that length extension property might apply to H (K0 Xor ipad) || text) (text is the salt in this case). However, the hash value here is an internal secret value, not available for the attacker.


For the former case, the hash function hashes the key first meaning it absorbs the entropy from the key (or randomizes the key, may be not perfectly) to produce K0. This case should not have less security than the case described in the previous paragraphs because hashing the key first additionally should not hurt security.


Regards,

Quynh.



When the key is no longer than hash block then you would need to assume what the compression function is a PRF when keyed via a non-uniform key, essentially assuming what you need to prove.



You can go ahead and use the reverse construction as an ad-hoc construction. However, if you want a detailed analysis such as in the case of HKDF , which is careful about lowering cryptographic assumptions, builds on the Merkle Damgard iterations (that are the basis of HMAC as PRF), is based on rich statistical extraction literature of 30+ years,  justifies the use of the function for many different settings (reflected very well in the use of HKDF in practical protocol, cf. TLS 1.3), and provides usage guidance, then I am not sure you can do it with the ad-hoc construction.



At the risk of repeating myself: while I appreciate what you’re explaining here, in my case staying with the lowest theoretic-proven cryptographic assumptions makes stuff undeployable in practice.



I really recommend you read the paper.  As I said at the beginning of this thread, I don't want to convert this into an exposition on HKDF. For that I wrote a full paper



I think I said that I have read that paper (I suspect that Quynh did too), and (in my case) found it targeting a different audience. No offence meant – but if it were more readable, I wouldn’t have to ask my questions here.