ML Algorithm Testing

[celic]

We've had several issues pop up reporting bugs on the ML algorithm testing. I'd like to collect that information into one place to help further the discussion, and ensure I can get all the fixes in at once.

🟢 = No reported issues
🟡 = Feature/fix implemented, not yet deployed
🔴 = Not implemented, in progress, reported issues around operations, i.e. vector set generation leads to error

Final Check refers to bringing the test implementation in sync with the expected final version of the algorithms. The current implementations are towards the Draft FIPS 203 and 204. Soon they will migrate towards FIPS 203 and 204.

ML-DSA

Algo	Mode	Property	Status	Related Issues
ML-DSA	KeyGen		🟢
ML-DSA	SigGen	deterministic	🟢	#322
ML-DSA	SigGen	non-deterministic	🟢	#322, #331
ML-DSA	SigVer		🟢
ML-DSA	Final Check		🟢

ML-KEM

Algo	Mode	Property	Status	Related Issues
ML-KEM	KeyGen		🟢
ML-KEM	EncapDecap	encapsulation	🟢	#327, #333
ML-KEM	EncapDecap	decapsulation	🟢
ML-KEM	Final Check		🟢

I'll be updating this discussion with more information as I dig into the problems.

[celic]

ML-DSA SigGen, AFT, non-deterministic, the server will provide a rnd value the IUT must use as input. The IUT returns the generated signature to the server that checks that the server matches the expected value. It appears this value is being inverted due to some endian-converters we use to represent BitStrings. This is confirmed by #331, thanks @mwcw.

ML-DSA SigGen, GDT, both deterministic or non-deterministic, the IUT generates a signature based on a key and message provided by the server. The server verifies the signature using ML-DSA SigVer, and returns that result. Reported in #322 with vsId: 2306885. Thanks @smuellerDD. My guess is this is the same issue as rnd and previously in #320 on the message being taken in during sigVer.

[celic]

#331, #322 fix is staged in our internal repository. Inverted the rnd value to match the expected endianess. Inverted the message input to SigVer (in Orleans) to match the expected endianess.

[livebe01]

The fixes for these issues was deployed to the Demo environment as part of today's hotfix deployment.

[celic]

#327 closed. We've got the fixes for the rest. We will make an announcement on the HOTFIX deployment when we are ready.

[celic]

#333 is fixed and staged. Not yet deployed.

[livebe01]

The fixes for these issues was deployed to the Demo environment as part of today's hotfix deployment.

[celic]

The CAVP has received comments from the FIPS authors on the content that will change between the draft FIPS and finalized versions. We will be implementing those changes. I understand they have been communicated to the pqc-forum but I'll summarize the changes closer to when we're ready to get them out.

[celic]

1. A check for a well-formed hint was added to HintBitUnpack
2. All bits of cTilde are used in SampleInBall now instead of the first 256 bits
3. The bits used from the XOF are now from the beginning of the output stream in ExpandMask
4. New structure has been added to identify an "internal" and "external" function for ML-DSA Sign and Verify. The CAVP will test the internal function with an arbitrary message.

[livebe01]

@celic are #'s 1-3 applicable to both ML-DSA and ML-KEM?

[celic]

Only ML-DSA, I'll need to do ML-KEM next week.

[livebe01]

These updates are now live on Demo for ML-DSA. See /~https://github.com/usnistgov/ACVP-Server/releases/tag/v1.1.0.34.

[smuellerDD]

Brief status: I was able to successfully test all ML-DSA and ML-KEM options, including all key sizes, keygen, siggen, sigver, encap and decap, and deterministic/non-deterministic signatures.

[celic]

Thanks for confirming. That's great to hear for the ML-DSA changes.

[celic]

The ML-KEM changes are already reflected by the server. Note Ahat[i,j] = SampleNTT(rho || j || i) is line 5 in K-PKE.KeyGen, and line 6 in K-PKE.Encrypt. This is present in the example files too.