SHA2 Testing Enforcing Seemingly Invalid Size Restrictions

[powersmc]

environment
Demo

testSessionId
None, can't generate successfully

vsId
None, can't generate successfully

Algorithm registration

            {
                "algorithm": "SHA2-256",
                "revision": "1.0",
                "messageLength": [
                    {
                        "min": 1720,
                        "max": 12144,
                        "increment": 8
                    }
                ]
                ,
                "digestSize": [
                    "256"
                ]
                ,
                "function": [
                    "SHA2"
                ]
            }

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):

For j = 0 to 99
    A = B = C = SEED
    For i = 0 to 999
        MSG = A || B || C || <'0' padding until len(MSG) >= minimum message length>
        MD = SHA(MSG)
        A = B
        B = C
        C = MD
    Output MD
    SEED = MD

[jbrock24]

Hi @powersmc, I'll be looking into this for you.

[jbrock24]

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.

[powersmc]

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.

[jbrock24]

I understand, I will work with team and get back to you.

[jbrock24]

@powersmc I'm going to create a custom vector set for you. Can you please provide me with your email? Thanks!

[powersmc]

@jbrock24 - It's michael.c.powers@leidos.com

[jbrock24]

@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.

[livebe01]

The fix for this is on Demo in release v1.1.0.28-hotfix-1.

[livebe01]

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.

[livebe01]

The fix for this is on Prod in release v1.1.0.28-hotfix-1.