Can HKDF accept empty IKM?

[wangweij]

I know IKM is the source of entropy and it's not safe to use an empty IKM. However, in my opinion it should still be legal. Including empty IKMs in the test suite can reveal implementation errors. For example, Java's SecretKeySpec class does not allow empty keys so it cannot be used to implement HKDF.

[bleichenbacher-daniel]

RFC 5869 doesn't define key sizes (unless I overlooked something). Hence this is a bit unclear. Generally, implementations should be allowed to restrict parameters. E.g., there are a lot of implementations that only support 12 byte nonces with AES-GCM. Having an implementation that does not allow empty keys is probably not such a bad idea as it detects cases where the coder forgot to initialize the key.
When in doubt, use NIST recommendations for lower bounds in a library. I don't think that anyone could argue that disallowing parameters below NIST recommendations is a programming error.

[wangweij]

Could we classify it as "acceptable"? This test case is still useful as it allows an implementation to either support it or provide a specific error message, rather than failing with an unrelated error due to the underlying key type not supporting an empty key.

[bleichenbacher-daniel]

Yes, I makes sense to add this as an edge case test. Libraries should either reject the key properly or compute the correct result and not return an internal error or worse.

Some discussion about empty keys in HKDF are here:
openssl/openssl#8531
openssl/openssl#12826

Somewhat related is:
CVE-2016-9243: HKDF in cryptography before 1.5.2 returns an empty byte-string if used with a length less than algorithm.digest_size.