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
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
- Use multiple calls to
HKDF-Expandto 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-Expandmultiple times generating up to
255 * HashLengthbytes 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
Infoparameter of HKDF-Expand. This way I won't keep deriving the same material.
- I noticed in the implementation of
HKDF-Expandthat I will be using, .NET, and also the RFC, it specifies that the
Infobuffer will be added to the hash right before the 8 bit counter variable. This means that if using some sort of integer counter for
Infois 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:
- Is it OK to use an integer counter for the
HKDF-Expand? I believe anything application specific and not related to the PRK is OK correct?
- Is it OK to generate so much keying data from a 512 bit PRK by exploiting the
- 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.