I'm trying to use HKDF-Expand to derive lots of keying material (> 64GB) from a pseudo-random 512 bit key.

Now according to the HKDF RFC, the maximum amount of keying material you can derive in a single call to HKDF-Expand is 255 * HashLength, which in my case would be 255 * 64 = 16,320 bytes of output (Since I'm using SHA512).

However, 16,320 bytes of output is not enough for me. But I figured I can go 2 routes to generate this data with HKDF-Expand:

  1. Use multiple calls to HKDF-Expand to derive multiple keys that are of size 16,320 bytes and concatenate them together. This theoretically doesn't break the RFC specification because I believe RFC allows you to call HKDF-Expand multiple times generating up to 255 * HashLength bytes of data each time.
    To do this, I will have a 32-bit counter for every key I derive, and I will pass this into the Info parameter of HKDF-Expand. This way I won't keep deriving the same material.
  2. I noticed in the implementation of HKDF-Expand that I will be using, .NET, and also the RFC, it specifies that the Info buffer will be added to the hash right before the 8 bit counter variable. This means that if using some sort of integer counter for Info is OK, then theoritically it should be OK to modify the 8-bit counter which is currently limiting HKDF-Expand's output length into something bigger, like a 32-bit counter. Thus, I can generate more key data.

My 3 questions are as follows:

  1. Is it OK to use an integer counter for the Info parameter to HKDF-Expand? I believe anything application specific and not related to the PRK is OK correct?
  2. Is it OK to generate so much keying data from a 512 bit PRK by exploiting the Info parameter?
  3. If question 2 is in fact OK, then doesn't that mean it should be possible to change the 8-bit counter than currently limits HKDF-Expand's output length to a larger counter, like 32-bits?

Thank you for any time here! I'm still a big Cryptography noob, so I apologize if these are stupid questions!

P.S. Also, in case anyone was wondering, the 512 bit PRK comes from PBKDF2, and the 64GB of keying data I need is more for experiemental purposes to see what I can do with HKDF.

  • 1
    $\begingroup$ Welcome to Cryptography.SE. 64GB is really too much key to generate from one key. I think it is better to talk about your actual problem and capabilities of your environment... $\endgroup$
    – kelalaka
    Commented Sep 18, 2022 at 10:24
  • $\begingroup$ @kelalaka Thank you for the advice. I understand that nobody really generates 64GB of keying data from HKDF, but would it be insecure in-practice? I think SHA512 should have enough bits for this right? Regarding the actual problem, this is more of an experimental project, to see what I can do with HKDF. $\endgroup$
    – Jon James
    Commented Sep 18, 2022 at 18:00

1 Answer 1

  1. Yes, there are no known bad interactions from this.
  2. Kind of. There are no known attacks on HKDF just from using the same PRK to generate a lot of keying material. If there was a problem already at 64 GB then I think that should be explicitly addressed in the RFC. If you just need a stream of deterministic key material then you could also consider e.g., CTR_DRBG using AES from NIST SP 800-90A. That can also use an (possibly vectorized) AES pipeline in the CPU to produce output at a high speed in an optimized implementation. There's presumably also been more cryptanalysis into generating large keystreams from AES, than HMAC-SHA-512. NIST limits that construction to $2^{48}$ calls of $2^{19}$ bits before a reseed is needed. I should also comment that a stream of key material of 64 GB seem pretty unusual.
  3. I guess it is 8 bits in the RFC because an output length 255*Hashlen bytes seems to be sufficient for keys/seeds used in practice. A larger counter could cost an additional compression function call in the hash function, depending on the length of 'Info'. Note that the counter is not specified to 8 bits in Krawczyk's paper (Section 4.2) https://eprint.iacr.org/2010/264.pdf.
  • $\begingroup$ Thank you so much for the detailed answer! Regarding question 3, I'm confused when you say that a larger counter could cost an additional compression function call. Why would this be the case? $\endgroup$
    – Jon James
    Commented Sep 18, 2022 at 17:57
  • $\begingroup$ The RFC wants to make sure that (info,counter) are unambiguously encoded in the HMAC message field. If using a fixed sized counter (1 byte today) to achieve that, then expanding counter to e.g., 4 bytes means less space for info if you want to make sure the whole encoding fits in one single message block in SHA-512. The blocks are processed using the internal SHA-512 compression function. $\endgroup$
    – erth
    Commented Sep 21, 2022 at 11:59
  • $\begingroup$ Thank you for the response! By fit into 1 single SHA-512 message block, do you mean 512 bits? If so, I'm not so sure how that would work. Because you first HMAC the previous hash, which is already 512 bits, and then you add the 1 byte counter along with the info. So there's no way it would fit into a single message block. $\endgroup$
    – Jon James
    Commented Sep 22, 2022 at 2:06
  • $\begingroup$ Block size is 1024 bits in SHA-512. I'm simplifying a bit. The point is that using a bigger counter uses more space in the message blocks, which can mean more compression function applications. $\endgroup$
    – erth
    Commented Sep 22, 2022 at 8:14
  • $\begingroup$ Ahh, OK, I understand now! Thanks so much for your help! $\endgroup$
    – Jon James
    Commented Sep 24, 2022 at 19:58

Your Answer

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

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