ParallelHash fails to encode n on zero length input, producing incorrect result.

[dghgit]

Testing ParallelHash128

{"tcId":967,
"msg":"",
"len":0,
"blockSize":126,
"customization":")7HY7q\u003C \u0027V!Rpq_l4:k(Ju$Q@:Qt]d1R:jRIQ~\u0027CWSQ*ADPNMZx%e5t23v9{?FCBFN8\u0026",
"outLen":16}

Produces "7F2F" in the sample answer. I can reproduce this if I comment out the encoding of n that is listed in step 4 of the algorithm:

4. z = z || right_encode(n) || right_encode(L).

where n is 0 as there is no data.

The correct answer appears to be: "ef5e"

[celic]

So even when n is 0, the right_encode(n) should cause some difference in z during this concatenation? I'll find time to take a look. Is this related to #912 ?

[dghgit]

Yes, that's correct even an n of zero produces a change.

This issue is not really related directly to #912, although obviously the ParallelHash is vulnerable to the same issue as it's based on cSHAKE, it's just that the size of the customization string needs to be reduced by the length of the function string to trigger a situation where the encoded N & S input is block aligned. It would probably be a good to include an appropriate customization string here too though. Personally, I can't imagine presenting ParallelHash, TupleHash, or KMAC for testing without including cSHAKE, but then I've seen a lot of things now that I could not have imagined, someone might present a device, or module, which only exposes one of the subsidiary algorithms, so including an AFT vector here which would also expose the issue would seem like a good idea.

[Kritner]

A fix for this is on demo

[dghgit]

I've been able to confirm this. Thanks, marking as closed.

[Kritner]

this change is now on production https://github.com/usnistgov/ACVP-Server/releases/tag/v1.1.0.12