Need more Flexibility in KDFs SP.800-56C and SP.800-108

[reneme]

Currently, there are some hard-coded assumptions. Let's take,

auto kdf = KDF::create("SP800-56C(SHA-256)");

... that will currently create a KDF that uses HMAC(SHA-256) for the extraction (which is fine) and hard-codes SP800-108-Feedback for the expansion. As far as I can see, there's no way to customize the expansion step (especially now that the concrete KDF-headers are internal). Or am I missing something?

Also, SP800-108 currently hard-codes the bitlengths for the counter and the encoding of the requested key lengths to 32 bits.

As it stands, customization of the mentioned hard-coded decisions should probably all be encodable using the algo-spec. Also, I believe, this can be done in a backward-compatilbe way using the existing bits as defaults. Albeit I foresee this to become somewhat cumbersome. Maybe #3275 would be useful here.

The fully-customized algo spec would probably look like this:

SP800-56C(SHA-256,SP800-108-Counter(SHA-256,8,16))

... with 8 and 16 being the bitlengths for the counter (aka r) and the key length L respectively.

[randombit]

😭 why could NIST not just standardize HKDF and be done with it

[Fine to extend this to handle these cases if you need them, I just greatly dislike how NIST keeps coming with new KDFs - we already implement 8 KDFs from various NIST SPs and they all have a zillion options]

[reneme]

Yep. Try adding BSI to the mix. 😏