Unexpected values in KMAC json files for bit-oriented key lengths

[dspdon]

There appears to be a problem in ACVP json file results for KMAC128, in test cases where key lengths are bit-oriented (not a multiple of 8 bits). All other test cases within the file for which key length is byte-oriented (a multiple of 8 bits) appear to be fine. For the KMAC128 json file, 291 of the 400 AFT test case results may be affected.

For bit-oriented key lengths, the json file contains message digest results that can be reproduced only by using an unexpected interpretation of the SHA3 "bytepad" function spec as defined in NIST SP 800-185 Sec 2.3.3. I believe the unexpected interpretation is incorrect.

Caveat: I found no alternative test vectors to corroborate results for bit-oriented key lengths.

Reproducing a small bit of NIST SP 800-185 Sec 2.3.3 (Padding):

"The bytepad(X,w) function prepends an encoding of the integer w to an input string X, then pads the result with zeros until it is a byte string whose length in bytes is a multiple of w. ..."

Also in this section are steps to achieve that:

1. z = left_encode(w) || X.
2. while len(z) mod 8 ~= 0: z = z || 0
3. while (len(z)/8) mod w ≠ 0: z = z || 00000000
4. return z

My interpretation of steps 1 and 2 suggests copying X verbatim, without inserting any zero bits before or within X, then padding z with 0 bits up to the next full byte.

Reproduction of ACVP json file results can be done by changing steps 1 and 2. Those steps would go something like this:

Given Nx = len(X), R = Nx % 8

1. z = left_encode(w) || leftmost_bits(x,Nx-R) || 8-R zeros || rightmost_bits(X,R).
2. skip (subsumed by above)
3. while (len(z)/8) mod w ≠ 0: z = z || 00000000
4. return z

The results in the ACVP json files can be reproduced by inserting 8-R number of 0-valued bits BEFORE the last R bits of X, where R = len(X) % 8. Making this change to bytepad allows my IUT to reproduce ACVP json file results exactly for ALL test cases in question. And I think these aren't the right results.

The key question to you: am I interpreting Sec 2.3.3 correctly?

If so, a simple guess: ACVP code may be invoking a byte-extend operation on X that returns an MSbit-aligned bitstream; reconfiguring as an LSbit-aligned bitstream may fix this. And a caution that SP 800-185 defines bit-direction in reverse from the usual.