Unexpected 'algorithm' header value in some SHA2 json files

[dspdon]

ACVP json files contain an 'algorithm' parameter in their header. The value of 'algorithm' in the json test files for SHA2-384, SHA2-512, SHA2-512-224 and SHA2-512-256 is set to 'SHA2-256'. I expected these values to match the algorithm file name, e.g., 'algorithm' would be 'SHA2-384' in the SHA2-384 json file, etc.

FWIW, I use the 'algorithm' value during local validation tests to confirm that code is testing what it expects to be testing. These values are requiring some manual overrides to continue to play fairly with my local test harness.

[livebe01]

Strange. The value for algorithm in the registration.json files seems to be correct. It's just the other files. Thanks for mentioning this. We'll take a look.

PS I was able to verify that this issue is isolated to the sample json files and does not affect vector sets requested from ACVTS Demo.

[dspdon]

A bit more to add to this. I can move this to a separate issue if you feel it is distinct.

The json test files for SHA2-384 (internalProjection.json), SHA2-512 (internalProjection.json), SHA2-512-224 (internalProjection.json) and SHA2-512-256 (internalProjection.json) have test vectors computed using SHA2-256. That is, the digest results recorded in the files are 256 bits in length, and the results can be reproduced by sending the messages through SHA2-256. The results do not correspond to SHA2-384, -512, -512-224 and -512-256. These are the same json files I cited above that have an incorrect 'algorithm' parameter value.

Also, in the same set of json files, there is an undocumented parameter named 'digestSize', which gets only a "slight mention" in the ACVP JSON specification document for SHA. The value for digestSize is 256, which seems suspicious as well in the SHA2-384 and SHA2-512 validation files. Regardless of the value, this parameter isn't well specified and should either be documented or simply removed.

FWIW the json files for SHA1, SHA2-224 and SHA2-256 appear to have correct responses when tested against a set of IUTs I am using.

[livebe01]

Thanks @dspdon. The additional information is helpful and most probably related.

As to digestSize, that's likely an artifact of how we're producing these sample files. It's automated. We can take a look to see what we'd need to do to be producing valid sample registrations for the SHA2 algorithms. I'm 95% sure that providing digestSize to one of our environments would not cause an issue. It'd just be something extra and would be ignored.

[jbrock24]

Hi @dspdon - the fix for this is implemented and will go out with the next version, thanks for pointing this out. We'll update here once that's been pushed.

[livebe01]

Hi @dspdon, this issue has been fixed as part of the v1.1.0.36 release.

[dspdon]

I downloaded the updated test files and ran them against my systems. All looks good. Thanks again for making these updates. --DonOn Oct 7, 2024, at 1:03 PM, livebe01 ***@***.***> wrote: Hi @dspdon, this issue has been fixed as part of the v1.1.0.36 release. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[jbrock24]

Great, thank you for letting us know it is fixed, and for alerting of the issue to begin with. Appreciated!