ML-DSA: Siggen GDT: rnd value missing?

[smuellerDD]

environment Demo

testSessionId 503548

vsId 2283716

Algorithm registration ML-DSA with deterministic and non-deterministic siggen

The GDT test vector for non-deterministic operation seems to miss the "rnd" value:

"tgId": 1,
        "testType": "GDT",
        "parameterSet": "ML-DSA-87",
        "deterministic": false,
        "tests": [
          {
            "tcId": 1,
            "message": "EF398A24AF163CC7C82A854EAF7760FE3E14FA29397B21C743242F5F7BA77E22ED4B6ACEB39C2A6E8F74DAB0C8241A43DA664EF58A6BBA5A083DC1DA85CB3BA2DA4E72CABB3A648C098495F4D6290505FEB52BB649597160152509182934F32468B0D9CE2919F9051D974EFBCBD0801155EB0E79F0A453B41D9BE3B440812458"
          },

When comparing that to the AFT tests, I see the "rnd" value to be used as "non-deterministic" data.

[celic]

For GDT, you generate your own rnd and provide the signature back to the server. The server will run the SigVer process to validate that the signature is a good signature.

Generally GDT, Generated Data Test, has the IUT generate most or all of the input values and provide them back to the server. I understand that this is harder to see because the documentation isn't ready yet.

[smuellerDD]

Am Donnerstag, 11. April 2024, 21:58:45 CEST schrieb Chris Celi:

Hi Chris,

For GDT, you are expected to provide the rnd used if deterministic = false.

Generally GDT, Generated Data Test, has the IUT generate most or all of the input values and provide them back to the server. I understand that this is harder to see because the documentation isn't ready yet.

And what about for GDT, deterministic=true?

Ciao Stephan

[celic]

You follow the expected process and generate a signature. The server will verify the signature via the SigVer routine in FIPS 204. In both cases, the server doesn't need to know rnd for the "testType" = "GDT" groups.

[smuellerDD]

Am Donnerstag, 11. April 2024, 21:58:45 CEST schrieb Chris Celi:

Hi Chris,

For GDT, you are expected to provide the rnd used if deterministic = false.

Generally GDT, Generated Data Test, has the IUT generate most or all of the input values and provide them back to the server. I understand that this is harder to see because the documentation isn't ready yet.

I updated the response with the used rnd value for GDT in deterministic = false, but I still get a complete failure.

Ciao Stephan

[smuellerDD]

Am Donnerstag, 11. April 2024, 21:58:45 MESZ schrieb Chris Celi:

Hi Chris,

For GDT, you are expected to provide the rnd used if deterministic = false.

Generally GDT, Generated Data Test, has the IUT generate most or all of the input values and provide them back to the server. I understand that this is harder to see because the documentation isn't ready yet.

Although I may not fully understand the code, but perhaps the following code part in the server is a problem?

gen-val/src/generation/src/NIST.CVP.ACVTS.Libraries.Generation/ML-DSA/FIPS204/ SigGen/DeferredTestCaseResolver.cs contains in method CompleteDeferredCryptoAsync the following:

var providedResult = new MLDSASignatureResult { PublicKey = serverTestGroup.PublicKey, Message = serverTestCase.Message, Signature = iutTestCase.Signature };

Specifically, the PublicKey is of interest. The code sounds like the server gets a server-generated public key for the given test. While this is true for AFT (as the server provides the SK to the client and thus needs its associated PK during validation), I am wondering whether this is correct for GDT? Shouldn't there be a special case for GDT to take iutTestCase.PublicKey?

Ciao Stephan

[livebe01]

This issue is addressed on Demo as of this afternoon's v1.1.0.34 hotfix deployment.

[smuellerDD]

After getting new vectors after the update, GDT still fails. But now in addition the AFT non-deterministic siggen fail which passed before. AFT determinism still passes.

vsid 2291240

[celic]

The documentation is now available on https://pages.nist.gov/ACVP. Does this answer any questions here to consider this resolved? Or is there still something I need to fix on the algorithm?

[smuellerDD]

Am Donnerstag, 25. April 2024, 15:20:59 MESZ schrieb Chris Celi:

Hi Chris,

The documentation is now available on https://pages.nist.gov/ACVP. Does this answer any questions here to consider this resolved? Or is there still something I need to fix on the algorithm?

I have looked at the documentation and implemented everything exactly as specified (at least to my understanding).

Status:

• before the hotfix some 2 weeks ago: siggen AFT completely passed, GDT completely fail

• after the hotfix: siggen AFT non-deterministic fails, GDT fails, AFT deterministic passes

This was achieved without any changes to my code.

That said, I was not able to identify what the issue is, considering that when AFT passes, the actual calculation seemingly are correct.

Let me try to get another test with samples.

Ciao Stephan

[celic]

Thank you. Any vsIds after the initial hotfix are helpful. I will be digging into this on Friday.

[smuellerDD]

Am Donnerstag, 25. April 2024, 15:20:59 MESZ schrieb Chris Celi:

Hi Chris,

The documentation is now available on https://pages.nist.gov/ACVP. Does this answer any questions here to consider this resolved? Or is there still something I need to fix on the algorithm?

I performed a debug session on ML-DSA siggen. Here are my findings:

• the sample vector is of no help as it misses the public key for performing cross checks.

• AFT siggen, non-deterministic (ie. with the rnd value): I use a construct to inject it into my Dilithium siggen which is identical to my Dilithium keygen implementation. As keygen passes, and after debugging, the right rnd value is injected during siggen, I think that the "correct" rnd value is used also for siggen on my side. Yet, the server thinks my responses are incorrect.

• GDT siggen: Considering that it always fails, and my code generates a keypair, I added a sigver operation for each siggen to check. Each sigver passes on my side. Yet, the server does not like the GDT answers.

AFT with deterministic operation passes, all others fail.

The vsID is 2306885.

Ciao Stephan

[celic]

I think I tracked down the issue. It's a bit hard to test for us, but I'm 95% sure this is the problem. When taking the message back in to run SigVer, the endianness was not factored into consideration. So we'd be verifying the signature on a different message than we sent the client, always leading to a fail. Further tracked in #332.

[livebe01]

The fix for this issue was deployed to the Demo environment as part of today's hotfix deployment.

[smuellerDD]

Confirmed, working