At first, we need to add/enhance new API for KDF in libgcrypt. Currently, the term "KDF" in libgcrypt is used with narrower focus, that is, only for password->key KDF.

What we will support are:

• ConcatKDF {Hash, HMAC} (NIST SP 800-56A)
• HKDF (NIST SP 800-56C), extract+expand and expand-only-skiping-extract
• Key Based KDF {HMAC, CMAC, KMAC} (NIST SP 800-108 rev.1 draft)

We would use gcry_kdf_open/gcry_kdf_final API, stretching the semantics a bit, but I wonder if it's good. Adding new API is better?

I learned that it's now called "OneStep KDF" in SP 800-56Cr2.
It's "SSKDF" in OpenSSL (Single Step KDF, perhaps).

For libgcrypt, if we use gcry_kdf_open/gcry_kdf_final API, minimum addition is:

In OpenSSL, it also supports two of hkdf variants: hkdf and tls13_hkdf.

I can only find this one: https://github.com/patrickfav/singlestep-kdf/wiki/NIST-SP-800-56C-Rev1:-Non-Official-Test-Vectors

I'll pick up two of tests for this.

Added HKDF implementation to master.

I am a bit confused about NIST inconsistency(?) for two-step KDF.

• NIST SP 800-108r1-draft defines KDF in Feedback Mode (and others)
• NIST SP 800-56C Revision 2 addresses RFC 5869 (of HKDF)
  • HKDF construction (extract-expand) is exactly same as the one in SP800-56C
  • But... HKDF uses different method in the expand step
    • In NIST SP 800-108r1, counter comes after K(i-1) and L is appended
    • In HKDF, counter comes at the end

It seems that implementations with HKDF can be certified as FIPS compliant. I don't know why.

I pushed the change needed for GnuPG to t5964 branch.
See: https://dev.gnupg.org/rGc281bd94349e4f7997a89927aaa2c2f45004b902

FIPS 140-3 (https://csrc.nist.gov/Projects/cryptographic-module-validation-program/fips-140-3-standards) points to SP 800-140Dr1 (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-140Dr1.pdf) to list acceptable "Security Parameter Generation and Establishment Methods". From this document, RFC 5869 (i.e., HKDF with the counter at the end) can be reached via two paths:

1. In section "6.2.8 Protocol-Suite Key Derivation", SP 800-140Dr1 links to section 7.1 of RFC 8446 (https://datatracker.ietf.org/doc/html/rfc8446#section-7.1), which describes the TLS 1.3 key schedule, which uses HKDF as Extract-and-Expand KDF and points to RFC 5869 (https://datatracker.ietf.org/doc/html/rfc5869) as its definition. As a consequence, HKDF as defined by RFC 5869 (i.e., with the counter at the end) must be approved at least for use in TLS 1.3.
2. Section "6.2.7 Key Agreement Key Derivation" of SP 800-140Dr1 references SP 800-56Cr2 (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr2.pdf). At the end of section 5.1, this document explicitly states that NIST considers RFC 5869 an extraction-then-expansion KDF according to this document: "RFC 5869 specifies a version of the above extraction-then-expansion key-derivation procedure using HMAC for both the extraction and expansion steps."

As a consequence, I do not expect problems when attempting to certify HKDF as specified in RFC 5869.

Pushed the change, although it is not enabled yet (since the feature will be only available by newer libgcrypt, 1.11).

Let's schedule that for 2.6