8
$\begingroup$

A KDF in Counter Mode (e.g., see NIST SP 800-108r1, Section 4.1, similar to HKDF) produces the output as what AES-CTR would do if one replaces AES with SHA2 (or, to be exact, with HMAC).

However, NIST, Section 6.3 does not recommend using the derived keying material as a key stream. As far as I understand, they mean the way it is used in AES-CTR.

How may AES be better than the SHA2 compression function (which is, in practice, a one-way function) where, in theory, a PRF is all that is needed for CTR?

Apriori, one can say that after you have sufficiently investigated AES-CRT, you can learn from it on any construction of this kind where another PRF substitutes AES unless some special characteristics of AES provide for security. I am not aware of them, though.

Improve this question
$\endgroup$
1
  • $\begingroup$ That statement is surprising given that all we need for CTR is a good PRF. So, there must be something deep that requires more interpretation? Also, my understanding of the NIST document is that it only deals with key expansion, and the PRF is effectively keyed with a random key. Which then generates random inputs for unique inputs labels just like in CTR... $\endgroup$
    – Marc Ilunga
    Dec 19, 2022 at 12:01

1 Answer 1

Reset to default
3
$\begingroup$

First a thing about terminology. SHA-2 is a a family of secure hashes. HMAC would be the most common PRF constructed from SHA-2, and it is an option to be used for a KDF. We'll ignore this for now as we can assume that the KDF construction that uses a hash can be considered a PRF.

KDF's have been designed with security in mind when it comes to generating a limited amount of keying material. In contrast, if you assume that you can use it as a stream cipher then you can assume that the key stream is generated as bulk, and at the discretion of the adversary.

Moreover, you'd have to prove that the common security principles (IND-CPA, IND-CCA) hold for the KDF. If that's not proven then you are basically using a cipher for which the common cryptanalysis is not performed. This is probably what is meant by the full statement by NIST:

The use of the derived keying material as a key stream (as in a stream cipher) is not recommended because the security of using KDFs as stream cipher algorithms has not been sufficiently investigated.

So they don't claim that this construction is worse than AES (although, given the state of AES, it can hardly be much better). They just say that they didn't investigate or include any studies towards using these kind of PRFs as stream ciphers.

In practical terms the choice is easier though. KDF's are usually pretty slow so this kind of thing would only be an option if AES is not available. Even then you could simply construct a ChaCha20/Poly1305 in software and have a better stream cipher.

If you are hell-bound to use a hash-like construction you could use one of the (authenticated) cipher modes constructed from Keccak, the sponge used for SHA-3.

Because of the availability of secure and efficient stream ciphers, I don't think that the community will be willing to perform a full review of KDF's as stream ciphers; KDF's are not a tool to directly achieve confidentiality.

That all said: hen it comes to practical security, I would not worry overly much if the construction would be used as practical attacks on this kind of PRF are unlikely to succeed. I'd however make sure that the stream cipher would be used on limited amounts of data for which the KDF was constructed.

Beware that many KDF constructions have special ways of handling requests for output keying material (OKM). They may limit the amount of output (see e.g. HKDF) or they may even include the size of the OKM in the calculation, in which case you have to know the size in advance.

Improve this answer
$\endgroup$
11
  • $\begingroup$ Sorry, @Maarten. Maybe because of the longevity of your text, I cannot see the answer to my question: why the same construction when it comes with AES is recommended, but when it comes with HMAC, it is not? $\endgroup$
    – uk-ny
    Dec 19, 2022 at 11:27
  • $\begingroup$ I am uncertain if I understand (or agree) with the answer here. The NIST document is about using PRFs specifically for key derivation (expansion in this case). The security of AES-CTR depends on the PRP-PRF switching lemma, and in fact we get better bounds if CTR is instantiated with a PRF instead of a PRP like AES. So, something is not really clicking in the NIST document. If we were talking about a general KDF, maybe, but we are talking about a PRF which has a proof of how to construct a IND-CPA encryption out of it (in CTR mode)... $\endgroup$
    – Marc Ilunga
    Dec 19, 2022 at 11:59
  • $\begingroup$ @MarcIlunga I agree with you and as I said, practically I don't see any issue with it. You extend that to theory and there is certainly a point to be made. The problem is that NIST is clearly not making this point, and I've indicated why I think they do not (I don't think we'll find a canonical answer). Maybe my answer is so extensive because "because the security of using KDFs as stream cipher algorithms has not been sufficiently investigated" leaves everybody guessing. I guess what is left is asking NIST for clarification. $\endgroup$
    – Maarten Bodewes ♦
    Dec 19, 2022 at 14:52
  • $\begingroup$ Note the question asked on SHA-2 and you replied with SHA-1. $\endgroup$
    – Meir Maor
    Dec 19, 2022 at 16:28
  • 1
    $\begingroup$ @MarcIlunga Too late in the day now, but I'll try and reach Lily Chen, the author of the NIST docs. I had an answer from her before - not one that I was hoping for, but an answer all the same. I'm starting to get interested in the reason myself. $\endgroup$
    – Maarten Bodewes ♦
    Dec 20, 2022 at 0:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.