3
$\begingroup$

I am attempting to implement a Key Based Key Derivation Function (KBKDF) in Counter Mode as part of a larger project. To test my implementation, I was directed towards the Verification System for this function (KBKDFVS) by this helpful question & answer.

I intended to generate tests for my code based on the full vector list downloadable here, but before that I decided to grab one sample vector as a simple hand-written test, and that's when I encountered some confusing discrepancies between the KDF as defined in SP800-108, and the algorithm as referred to in the KBKDFVS.

Firstly, the KBKDFVS (and the test vectors) indicate that multiple counter locations (before, middle, after) should be supported:

3.e Order of the fixed input data: Does the IUT support the counter coming before, in the middle, and/or after the fixed input data?

However, the original document makes no allowance for variable location of the counter in the input string, it is explicitly at the beginning of the bitstring:

K(i) := PRF (KI, [i]2 || Label || 0x00 || Context || [L]2)

This bitstring definition for each iteration of the PRF highlights another issue with the test vectors, which can be seen in this example:

[CTRLOCATION=BEFORE_FIXED]
[RLEN=16_BITS]

COUNT=0
L = 128
KI = 26ef897e4b617b597f766ec8d8ccf44c543e790a7d218f029dcb4a3695ae2caccce9d3e935f6741581f2f53e49cd46f8
FixedInputDataByteLen = 60
FixedInputData = bc2c728f9dc6db426dd4e85fdb493826a31fec0607644209f9bf2264b6401b5db3004c1a76aa08d93f08d3d9e2ba434b682e480004fb0d9271a8e8cd
    Binary rep of i = 0001
    instring = 0001bc2c728f9dc6db426dd4e85fdb493826a31fec0607644209f9bf2264b6401b5db3004c1a76aa08d93f08d3d9e2ba434b682e480004fb0d9271a8e8cd
KO = a43d31f07f0ee484455ae11805803f60

The "instring", the value which is input to the PRF in addition to the key, is simply the concatenation of the counter (i) and the fixed input data (Label || 0x00 || Context). The binary representation of L is simply not present.

With L in the input string my implementation's KO does not match the output of the vector, but if I modify my implementation to omit L from the input string, my KO matches that of the input vector, so I do not believe the authors simply omitted this step from the vector data while still including it in the output.

My actual question: Is anybody able to explain this inconsistency to me? Why do the test vectors seem to disagree with the specification of the algorithm? And if it is simply an error or outdated data, is there a better way to verify my implementation?

Handy Links: SP800-108 itself SP800-108 KBKDFVS

$\endgroup$
1
  • 1
    $\begingroup$ I can remember that I thought that there were some horrid inconsistencies at the time, but as I proposed the Bouncy Castle KDF implementations I think I must have figured out something at the time. I did implement test vectors, no idea if those made it in there... $\endgroup$
    – Maarten Bodewes
    Sep 1, 2020 at 14:39

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.