Closed powersmc closed 1 year ago
Hi @powersmc, I'll be looking into this for you.
This testing produces AFT and MCT vector sets with LDT being the only optionally produced test group ( noted in 7.2 ). To generate and test this algorithm, the input requirements should be valid for both AFT and MCT production. This means that the message lengths min will need to meet the bounds standard (digest*3 >= min). Unfortunately, your request isn't getting past parameter validations. Thank you.
Yes, @jbrock24 - I want to make it clear though that those size input requirements are not coming from the SHA standard (i.e.: FIPS 180-4) but are just coming from how the MCT test is designed. This restriction is preventing a completely valid / correct SHA2-256 implementation from being certified.
I understand, I will work with team and get back to you.
@powersmc I'm going to create a custom vector set for you. Can you please provide me with your email? Thanks!
@jbrock24 - It's michael.c.powers@leidos.com
@powersmc I am currently finishing up the testing for this and will hopefully roll it out for next release. At that time the current requirements for testing will be removed and your min/max should work natively. Will reply here with a rough estimate for the release date.
The fix for this is on Demo in release v1.1.0.28-hotfix-1.
PS We had to update the way SHA MCT tests are accomplished for this. See https://pages.nist.gov/ACVP/draft-celi-acvp-sha.html#name-monte-carlo-tests-for-sha-1 to understand the updated SHA MCT testing.
The fix for this is on Prod in release v1.1.0.28-hotfix-1.
environment Demo
testSessionId None, can't generate successfully
vsId None, can't generate successfully
Algorithm registration
Endpoint in which the error is experienced /acvp/v1/testSessions POST
Expected behavior We would expect that this request would succeed, but the server is providing the response "SHA2-256-1.0: Message length must contain the digest size and 3x the digest size for MCT". This seems like an odd restriction, as the input length (message length) is not correlated at all with the output length (digest length) - so there shouldn't be any dependencies between the two.
From what I'm seeing, this seems to be a "side effect" based on how the MCT works, in that the hash function is fed an input that is 3x the digest size in a loop. That being said - the standard (180-4) doesn't impose any restrictions like that, so this seems to be more of a shortcoming in how the testing works, and not a restriction coming from the standard itself.
Additional context At a glance there doesn't seem to be a quick fix for this. It seems like one could either: -Remove the MCT entirely when the module doesn't support the necessary message lengths (i.e.: 3x the digest length), and only include the AFT/LDT items -Re-work how the MCT operates, for example something like this (which shouldn't break any backwards compatibility, as the padding wouldn't be appended in the scenario where len(MSG) is already >= the minimum):