KDF 108 middle fixed data chaniging

[jbdean1968]

We have a vendor who previously under FIPS 140-2 had tested KDF 108 Counter mode with the middle fixed data selection. Their code has the same position (15) for the middle fixed data field and the same fixed data used for the testing.

For the CAVS tool, the .req file only provided the key input (KI) and the vendor was able to provide all the other information as a part of the .resp file and the test provided the key output (KO). An example is below

From the sample file COUNT=0 L = 8 KI = a0843d8e7e26b46d7e6725368aa26a92 DataBeforeCtrLen = ? DataBeforeCtrData = ? DataAfterCtrLen = ? DataAfterCtrData = ? KO = ?

From the response file COUNT = 0 L = 128 KI = c6b1c3d7eb54697c8c7d0a0e0b175384 DataBeforeCtrLen = 15 DataBeforeCtrData = 000000000000000000000004000080 DataAfterCtrLen = 16 DataAfterCtrData = D2BF2CDBB5834D03722E71FBF83E3738 KO = 818F483D3AE7C9EC47E3BF6F1D3E7AFA

COUNT = 1 L = 128 KI = 3f0d7d5823baeab30417ac91838622a3 DataBeforeCtrLen = 15 DataBeforeCtrData = 000000000000000000000004000080 DataAfterCtrLen = 16 DataAfterCtrData = D2BF2CDBB5834D03722E71FBF83E3738 KO = F115C2A98E83C7678974003087D5D949

So for ACVP KDF 108 testing, the required info is the same, the KI but the expected file shows different break locations (instead of 15) and different fixed data (see below) There is no way to know the specific locations based on just the KI

"tgId": 1, "tests": [ { "tcId": 1, "fixedData": "584C1309E60DAFF89DEF425E76F40B6E", "breakLocation": 65, "keyOut": "00" }, { "tcId": 2, "fixedData": "624EC7CE6886D98BAC0092034677A019", "breakLocation": 98, "keyOut": "80"

This is a response from the vendor "tgId": 1 "tests": [ { "tcId": 1 "fixedData": "000000000000000000000004000080D2BF2CDBB5834D03722E71FBF83E3738", "breakLocation": 15, "keyOut": "EBA131423C59D21E06DC4A76215BF270", }, { "tcId": 2 "fixedData": "000000000000000000000004000080D2BF2CDBB5834D03722E71FBF83E3738", "breakLocation": 15, "keyOut": "47EEC10FC8B67EE33CAA3D77C72FE092", }

What is required for the testing as the vendor is having issues with this output

[GlennUL]

@livebe01 Do you have any feedback on this situation? Is this due to it being a sample and the ACVP server by default uses random break locations in the provided expected file whereas under regular testing the vendor would not be expected to use random break locations if they don't support such?

[livebe01]

Thanks for the ping on this @GlennUL. We'll take a look and get right back with you.

[livebe01]

Above, I'm seeing what looks like 2 json blurbs. The second of the two blurbs looks like a response file from the vendor. What is the first json blurb? Are those the "expected" answers from a Demo vector set produced with "isSample": true?

If so, I think that may be the source of the confusion. Normally, the server cannot calculate the answers beforehand for a KDF counter vector set. It cannot calculate the answers beforehand as it needs the IUT to send back additional information such as the values for "fixedData" and "breakLocation". But, when "isSample": true is selected, the server fills in values so that it can produce sample expected answers.

I believe that giving your vendor a test run with "isSample": false will resolve your issue.

[jbdean1968]

The first blurb is actually the response file for the old CAVS tool which they were able to do previously. As it was different for the ACVP server and didn't seem to allow a specific place to enter the middle fixed data the same way. I will try what you suggest.

Thank you

[jbdean1968]

@livebe01. Is it possible to get an answer file based on set fixed data and location. We have rerun the test vectors not selecting the "this is a sample" option. When the vendor ran their test, they sent back the response file but we still received an error. All it said was that the keyout does not match. We have nothing to troubleshoot with and nothing to compare to.

[livebe01]

What was your vsId on Demo?

[jbdean1968]

vsId: 2105409

[jbdean1968]

@livebe01. I wanted to follow up to see if you were able to look at this

[livebe01]

Apologies for the delay. I'll be able to look at this today.

[livebe01]

@jbdean1968 can you confirm that your vendor's IUT uses a 32 byte fixed input data?

The fixedData being supplied by the IUT is: "000000000000000000000004000080D2BF2CDBB5834D03722E71FBF83E3738"

When ACVTS verifies the value supplied for keyOut, it forms the fixed input data as follows:

Bits 0 - 14 from the supplied fixedData value || 8-bit counter value || bits 15 - 247 from the supplied fixedData value.

This can be seen here: https://gitlab.nist.gov/gitlab/cvp/cavp/genvals/-/blob/develop/gen-val/src/crypto/src/NIST.CVP.ACVTS.Libraries.Crypto/KDF/CounterKdf.cs?ref_type=heads#L21

Can you confirm that this is how you/the vendor are expecting the testing to function? If the answer is yes, I'll work up a test vector set that includes the answers we're expected to assist in troubleshooting.

[livebe01]

I took a look at the files associated with vsId: 2105409 and re-ran the validation locally. I'm not sure why we're not including the "expected" vs "provided" keyOut values when a test case fails by default on ACVTS, but see the attached file for those values. Hopefully this will get you closer w/ your troubleshooting...

Validation.json

[jbdean1968]

@livebe01

I have sent on the information to our vendor and I will get back to you when I know more. Thank you for this information

[livebe01]

Hi @jbdean1968, checking whether this ticket can be closed. Thanks.