One Step KDF (56C - Question or Bug)?

[mtdownz]

Protocol Section https://usnistgov.github.io/ACVP/draft-hammett-acvp-kas-kdf-onestep.html#name-registration-example

Protocol Question When attempting to request vectors for the OneStep KDF (56C) using HMAC-SHA-256 using an L value = 256 bits the ACVP Demo server returns an error requesting a minimum of 512-bits for the length L. Is this the correct behavior as the output from the HMAC-SHA-256 is 256-bits? Also, what is SHA2_D256 as stated in the error message?

Output: ACVP [ERR][log_network_status:1491]--> 400 error received from server. Message: ACVP [ERR][log_network_status:1492]--> [ { "acvVersion": "1.0" }, { "error": "Validation error(s) on JSON payload.", "context": [ "KAS-KDF-OneStep-Sp800-56Cr1: Provided \u0027l\u0027 value of 256 does not meet the minimum l value of 512 for the function SHA2_D256."

Thank you.

JSON Request: [{"acvVersion":"1.0"},{"isSample":true,"algorithms":[{"algorithm":"KAS-KDF","mode":"OneStep","revision":"Sp800-56Cr1","prereqVals":[{"algorithm":"HMAC","valValue":"same"}],"fixedInfoPattern":"algorithmId||l||uPartyInfo||vPartyInfo","encoding":["concatenation"],"auxFunctions":[{"auxFunctionName":"SHA2-256","macSaltMethods":["default"]}],"l":256,"z":[512]}]}]

[Kritner]

"SHA2_D256" is just an internal representation of that particular hash function for us, I'm guessing there may be a few cases throughout the system that returns such internal representations (since they've only recently started being sent to the user).

As far as the 2x the largest output length of the selected auxFunctions, that was to attempt to ensure a more thorough testing of the underlying KDF, namely multiple iterations through the KDF loop. Since such a KDF validation can be used in conjunction with SSC testing, the idea is to get as much of the underlying algorithm tested as possible; since the two (kdf and ssc) are only tested "together" in the "full kas" testing.

[swkeypair]

We have a validation in process that implements the SP 800-56C One-Step Hash KDF to generate a 256 bit key. The implementation does not support arbitrary / larger sizes of generated key material. The testing lab engineer (rightfully) would prefer that the ACVP testing is representative of what the module will do.

We request that this test be updated to permit at least l=256.

Thank you

[EH-Acumen]

The SP 800-56C standard does not specify that the 2x the largest output length of the auxFunctions needs to be supported. It does not seem right to introduce new testing requirements that the SP 800-56C does not require.

[Kritner]

I'll put in an update to remove the 2x output of the underlying hash restriction

[Kritner]

This change is on demo

[swkeypair]

Thank you very much!

[EH-Acumen]

When can we expect the change to be reflected on the Prod server?

[Kritner]

This change is on production in release v1.1.0.14