Closed blackbird1999 closed 1 year ago
Sorry we haven't had a chance to get to this yet. Just letting you know that we haven't missed it.
I am currently investigating this and will get back to you shortly.
thanks, joel. to be clear, this is just a problem with the draft document... the latest sample test vectors we received produced the expected outputs when the feedback i suggested above was performed, so the current software appears to be correct.
So when looking through the code, workingBits = Left(T[i-1][0] || ZeroBits(288), 288);
is accurate. You can see here the code used for this:
var innerBitString = BitString.ConcatenateBits(innerTuple.ElementAt(0), BitString.Zeroes(288))
.GetMostSignificantBits(288);
This doesn't seem to be inaccurate. Thanks!
Hi Joe,
The issue isn't with the code, it's with the draft documentation. The documentation needs to be updated. Thanks!
"The main problem here, though, is that the line:
in the TupleHash MCT pseudocode (see draft-celi-acvp-xof.html#name-tuplehash-monte-carlo-test) should be
with Output[0] properly initialized to the input tuple (rather than putting that in T[0][0])!
As the pseudocode stands, there is no feedback between the output of the hash function and workingBits -- in fact, its first 9 bytes and those of T[i][0] remain invariant, so tupleSize is also invariant. Clearly that is not what the server is executing.
Originally posted by @markowitz-isc in https://github.com/usnistgov/ACVP-Server/issues/211#issuecomment-1146751667"