livebe01
commented
1 month ago I'm pasting in info from @LikelyLee below (see https://github.com/usnistgov/ACVP-Server/issues/349#issue-2427642629):
- SHAKE length used in ECDSA issue: ECDSA with SHAKE as XOF algorithm, the hash output length does not follow the statement in FIPS 186-5 Section 6.4: "When SHAKE128 or SHAKE256 is used as an XOF in Sections 6.4.1 and 6.4.2 below, its output length shall be 256 or 512 bits, respectively."
Current situation:
-
For normal testing siggen / sigver: SHAKE-128 output 128 bits and SHAKE-256 output 256 bits which could be successfully validated
-
For the component testing siggen / sigver: the "message" shall be first truncated leftmost 128 bits for SHAKE-128 and 256 bits for SHAKE-256, and then could be successfully validated
Expected behavior:
-
For normal testing siggen / sigver: SHAKE-128 output 256 bits and SHAKE-256 output 512 bits which could be successfully validated
-
For the component testing siggen / sigver: no truncation on the "message" to be successfully validated
- ECDSA and SHAKE Combination issue: ECDSA siggen / sigver with P-384 and P-521 shall not paired with SHAKE-128 since the output bits are not match the security strength. But now acvp server could request such combination and validate the results.
SHAKE variants of the ECDSA signature algorithms appear to be using truncated digests.
We've found we can pass on demo by truncating SHAKE128 to 16 bytes and SHAKE256 to 32 bytes.
FIPS PUB 186-5 Section 6.4 states "An approved hash function or an XOF shall be used during the generation of digital signatures. Approved XOFs are SHAKE128 and SHAKE256, which are specified in FIPS 202. When SHAKE128 or SHAKE256 is used as an XOF in Sections 6.4.1 and 6.4.2 below, its output length shall be 256 or 512 bits, respectively."