Score:8

Crypto

AES vs. SHA2 in key-stream generation

uk-ny

12/18/23, 4:20 PM

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.

168

1 + 1

aes

xor

stream-cipher

sha-256

kbkdf

Marc Ilunga

12/19/23, 12:01 PM

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...

Score:3

Crypto

Maarten Bodewes

12/18/23, 6:41 PM

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.

+ 11

uk-ny

12/19/23, 11:27 AM

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?

Marc Ilunga

12/19/23, 11:59 AM

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)...

Maarten Bodewes

12/19/23, 2:52 PM

@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.

Meir Maor

12/19/23, 4:28 PM

Note the question asked on SHA-2 and you replied with SHA-1.

Marc Ilunga

12/19/23, 11:28 PM

I hope we get some insights here. But to me there's almost a contradiction in the state of affairs: either the security proof of CTR (which requires a PRF is wrong) or I am not reading the NIST document correctly. It would make sense to me if the KDF was an extractor so reusing the IKM is probably not good. But in case we are using a good PRF with a random key? I mean isn't HKDF insecure as well by then same token?

Marc Ilunga

12/19/23, 11:36 PM

My other guess for the recommendation is protection against key reuse maybe? Maybe the idea is that the API of a KDF isn't that of a PRF to which we pass a nonce/counter but the CTR mode of the KDF is "internal" so 2 calls to the KDF will return the same value, breaking CPA security. Just a guess but even this should not really be a vulnerability per se. We could probably use a label to get unique inputs to the PRF and get back to the correct CTR API. I am definitely interested in knowing the reason.

Maarten Bodewes

12/20/23, 12:28 AM

@MeirMaor OMG, I even wrote that SHA-1 is a secure hash. Sorry, that was a serious brainfart. Not that it is necessarily insecure in this operation, but still.

Maarten Bodewes

12/20/23, 12:30 AM

@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.

uk-ny

1/2/24, 3:47 PM

I see that this topic has been discussed in [Comments on NIST SP 800-108r1](https://csrc.nist.gov/csrc/media/Publications/sp/800-108/rev-1/draft/documents/sp800-108r1-draft-comments-resolutions.pdf), but still, the decision by NIST to write "not recommended" needs explanation. @MaartenBodewes, how can I contact Lily Chen?

Maarten Bodewes

1/2/24, 4:26 PM

Just send her them email, it's just starting with their full name with a dot in the middle & ending with the last two parts of the website name of NIST (it's an organization). Sorry, didn't do this as this was at a pretty busy time for me. Note that this is a governmental organization (ending with .gov), it may take some delays especially at this particular moment in time. If you have a second, let me ask her if she's open to this.

Maarten Bodewes

1/2/24, 4:42 PM

@uk-ny Hmm, given that this would spam her mail address with two mails I've decided to put the question in the mail. I'll let you know the response. If we're unlucky it simply states that it isn't researched instead of stating which requirement isn't met, but we'll have to see.

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: AES vs. SHA2 in key-stream generation

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.