HKDF is commonly used to derive key material just in time for its application. However, as a cryptography tool, HKDF is severely under documented and lacks prescriptive examples for intended use.
A large-tech blog shared their HKDF application and I identify several issues with its implementation. Inside is an anonymized version with critiques and improvements.
@cendyne The string prep on the inputs is pretty weak. I discovered that the hard way.
KMAC is much better since the input prep properly incorporates the input lengths and using a SHAKE means it is pretty much foolproof.
@hallam hey Phillip, would you share a concrete description in how they are weak?
Also, speaking of SHAKE, have you heard of duplexes? https://codahale.com/the-joy-of-duplexes/
It incorporates similar idea that safely and strongly separates inputs into hidden state.
@cendyne I can’t remember exactly but the info tag is just planked in without any length identifier so a null tag is the same as all zeros.
Easily avoided but just sloppy work. One of the things that worries me about using formal proofs is that almost none of the people in a WG have the ability to evaluate one and those who can mostly don’t have the inclination. And so we tend to end up with less than robust work because the specifications are incomplete.
My college tutor used to point out that asked to specify a sort function, most people overlook stating that the output be a permutation of the input.
@hallam this is where NIST requirements can be quite helpful as a reference for such attention to detail. The NIST HKDF req’s include a bit count appended to the info input. (Though it’s intended endianess eludes me)
By WG, do you refer to the IETF CFRG, JOSE WG, and others in the IETF and OASIS, W3C, et al umbrellas?
I do believe that through my own struggles to comprehend these papers, that they are incredibly inaccessible to the applied field. (And this is something I am trying to help)
Cendyne
Phillip Hallam-Baker