SP800-56C rev 1 HKDF test spec

[smuellerDD]

The HKDF test spec may need a bit of love.

Chapter on test vectors:

• algorithmID not present

• description of l missing - note, looking at the expected value, this field seems to be a byte value and not a bit value

[smuellerDD]

SP800-56C rev 1 HKDF testing successfully completed - vsID 365582

[Kritner]

description of l missing - note, looking at the expected value, this field seems to be a byte value and not a bit value

Can you elaborate on this about the byte vs bit value? the value l itself as registered and in the vector set information should represent the number of bits to derive keying material for, represented as an int. When "plugged into" fixed info that same int value that represents the number of bits to derive should be represented as a 32 bit bitstring. So an l of 512 becomes "00000400" as the "portion" of the fixed info that represents l (assuming that l is included as a part of the fixed info).

[smuellerDD]

Am Mittwoch, 28. Oktober 2020, 19:35:09 CET schrieb Russ Hammett: Hi Russ,

> description of `l` missing - note, looking at the expected value, this > field seems to be a byte value and not a bit value Can you elaborate on this about the byte vs bit value? the value `l` itself as registered and in the vector set information should represent the number of bits to derive keying material for, represented as an int. When "plugged into" fixed info that same int value that represents the number of bits to derive should be represented as a 32 bit bitstring. So an `l` of 512 becomes "00000400" as the "portion" of the fixed info that represents `l` (assuming that `l` is included as a part of the fixed info).

I registered an l of 2048. Then I pulled a sample file that showed 4096 hex characters for the dkm == 2048 bytes. I also generated 2048 bytes dkm in my response file and that was accepted. This indicates that l is a byte value. Ciao Stephan

[Kritner]

Thanks @smuellerDD I'll make an update to the specification to account for l, and make a correction on our side so that l represents the DKM length in bits rather than the current (and incorrect) bytes.

[Kritner]

This change will be on demo from release v1.1.0.14 after the scheduled maintenance.

[smuellerDD]

Confirmed, working.

[Kritner]

This change is on production in release v1.1.0.14