Testing SHA3 when not all messages lengths are supported

[jk-acumen]

Section
https://usnistgov.github.io/ACVP/draft-celi-acvp-sha3.html#name-sha3-and-shake-algorithm-ca

Question
Since SHA3 does not support a messageLength parameter (the way SHA2 does), how can we test a SHA3 implementation that only supports specific message lengths?

This scenario does seem to be allowed in FIPS 202: "A conforming implementation of a SHA-3 function may restrict the set of supported bit lengths for messages."

[smuellerDD]

Am Montag, 14. September 2020, 08:16:06 CEST schrieb jk-acumen: Hi jk,

**Section** https://usnistgov.github.io/ACVP/draft-celi-acvp-sha3.html#name-sha3-and-sha ke-algorithm-ca **Question** Since SHA3 does not support a messageLength parameter (the way SHA2 does), how can we test a SHA3 implementation that only supports specific message lengths? This scenario does seem to be allowed in FIPS 202: "A conforming implementation of a SHA-3 function may restrict the set of supported bit lengths for messages."

The server seems to silently accept the messageLen parameter without honoring it. As all my SHA3 implementations take arbitrary lengths, I did not notice that even though I send a messageLen to the server. After trying, say, a messageLen of 0 to 128 bits, the server still returns vectors with much longer messages. Ciao Stephan

[celic]

MessageLen is a bit awkward here. It is only used for the MCTs behind the scenes. The MCTs need an upper and lower bound if the defaults are not supported and so the domain really is just that. One range of values. The MCTs cannot handle if I were to provide (1-10, 15-20) as bit lengths due to some integer parsing of bits. We get around this by performing a modulus over the range provided which is straightforward if a domain like (1-20) is provided. Again, these values are not used for the AFTs.

With how the MCTs are designed (from CAVS), I'm not sure if SHA3 will be able to handle the parameter like SHA2 (which appends the last 3 full digests together for the MCT message rather than trying to form a message of a specific size).

[mtdownz]

This ability is critical to some of our vendors. For example, we have a vendor that whose module tests only message lengths incremental by 32-bits. It seems that SHA3 testing is really not ready for prime time. If the ability to control the message lengths is not going to be available for SHA3 validations then can SHA3 be continued to be submitted as "Vendor Affirmed"?
Thanks!

[celic]

Testing still needs to happen. Send me an email and we can work something out.

As for why SHA3 is so different than SHA1/2, it is because of SHAKE. Our testing implements both functions together. SHA1/2 use the same code to generate tests, and SHA3/SHAKE use the same code to generate tests. For SHAKE there is a lot of complexity in the MCTs that does not carry over to SHA3. This could be solved by finally breaking them out into separate code bases for test generation. I'll see how much work this is, but please do send me an email so we can talk about timelines.

[mtdownz]

Chris, I'll email you directly on Monday with the information with respect to one of our vendor's implementation.
Thanks.

[celic]

Stay tuned for SHA3 revision 2.0 which allows a registration similar to SHA2. Documentation in progress.

[celic]

This is on the demo server. Documentation is not completed yet. A registration looks like this...

{
  "algorithm": "SHA3-224",
  "revision": "2.0",
  "isSample": true,
  "messageLength": [
    {
      "min": 0,
      "max": 65536,
      "increment": 1
    }
  ],
  "performLargeDataTest": [
    1,
    2,
    4,
    8
  ]
}

[mtdownz]

Excellent, thank you!

[Kritner]

This change is on production in release v1.1.0.14