livebe01

Great. We're on the same page. We've updated the CCM-ECMA tests to correctly note the ivLen value for the supplied iv. This change will be included in the next release...

The fix for this is on Demo in release [v1.1.0.41](https://github.com/usnistgov/ACVP-Server/releases/tag/v1.1.0.41).

Hi @dspdon, can you confirm that you are still looking to get intermediate values for bit-oriented cSHAKE MCT tests? Thanks, Ben

I'm pasting in info from @LikelyLee below (see https://github.com/usnistgov/ACVP-Server/issues/349#issue-2427642629): > 1. SHAKE length used in ECDSA issue: ECDSA with SHAKE as XOF algorithm, the hash output length does not follow...

Thanks for reporting this @dghgit and @LikelyLee. The output lengths for SHAKE and ECDSA was something we addressed in a previous [release](https://github.com/usnistgov/ACVP-Server/releases/tag/v1.1.0.34), but we appear to have reverted those changes....

Hi @dghgit, @LikelyLee, we just deployed the fix for this issue to Demo as part of the [v1.1.0.36](https://github.com/usnistgov/ACVP-Server/releases/tag/v1.1.0.36) release. Would either of you be able to test it to confirm?...

Great, thank you David!

The fix for this has been deployed to ACVTS Prod as part of the [v1.1.0.36](https://github.com/usnistgov/ACVP-Server/releases/tag/v1.1.0.36) release.

Thanks for sharing this. We'll take a look. By the way, I'm curious how you discovered this. Were you testing an ECDSA implementation and found that some test cases were...

@mcarrickscott acknowledged. You mentioned attempting to reproduce the NIST test vectors. The test vectors you're referring to, are these test vectors you've produced by interacting with ACVTS Demo? If so,...