External Interface Testing for ML-DSA

[Celi, Christopher T. (Fed)]

Hi all,

 

The Cryptographic Algorithm Validation Program has finished work on ML-DSA external interface testing. Attached is a complete set of test vectors, and a set of intermediate values for ML-DSA SigGen. We will be working to publish this on CSRC and to the test platform, ACVTS soon. Also included is a file that steps through a series of runs on just the external interface with intermediate values. This covers every hash supported by NIST, with the OIDs. Lastly, this includes testing for what we’ve called the “external mu computation” option of ML-DSA. This allows mu to be computed in full externally to the module and provided to the internal signature interface. This is included in the test vector JSON files only, this should be easy to reconstruct using existing intermediate values for ML-DSA SigGen.

 

For those unfamiliar with the CAVP file formats, the prompt.json file contains properties describing a series of tests within a test group, labeled with a test group identifier, tgId. Individual inputs are provided as test cases, labeled with a test case identifier, tcId. The expectedResults.json contains the outputs associated with the prompt.json. In other words, tcId 1 from the prompt.json will produce the content in tcId 1 from the expectedResults.json. Both sets are combined in the internalProjection.json, also identified with a tcId.

 

Please let me know if you have any questions. I’ll be sure to upload a full set of files for CSRC. The files are a bit large, hopefully the forum lets these through.

 

I will be working on SLH-DSA to include testing for the external interfaces next week.

 

Thanks,

Chris Celi

CAVP Program Manager

[niux_d...@icloud.com]

+1

Some problems I found.

In "ml-dsa-intermediate-values", the "external-prehash-sign-ml-dsa-8-sha3-512.txt" seems to be corrupt - I opened it, and it started in the mid of an array, instead of the "message:" label.

Also, only SHA-512 prehash is the one currently with OIDs defined, but the test cases test other hashing algorithms. What's your take on this?

Thanks.

Pax~ DannyNiu/NJF.

-- 
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CO6PR09MB75916EB937659733BAD07DBEF02E2%40CO6PR09MB7591.namprd09.prod.outlook.com.
<ml-dsa-intermediate-values.zip><ML-DSA-SigGen.zip>

[niux_d...@icloud.com]

I'm having difficulty reproducing the external hedged signing results in "ML-DSA-sigGen-FIPS-204/internalProjection.json". 

Specifically test group 5, 6, 13, 14, 21, and 22. My code is not producing varying result, so I suspect if your code is relying on a TRNG for what's supposed to be semi-deterministic - the hedged signing.

Can you check if you can produce static results across different tries, meanwhile I'll be check my code more deeply.

Thanks.

Pax~ DannyNiu/NJF.

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/056A9F2B-ACAC-4D1B-8500-5D704ED48ED5%40icloud.com.

[Markku-Juhani O. Saarinen]

Hi Chris,

Looking "prompt.json" in ML-DSA-SigGen.zip, this set seems to include test cases for SHA2-224, SHA3-224, and SHA-512/224 prehashes, which (at 112 bits of collision security) do not meet the security requirements at PQC Category 1 (let alone ML-DSA-44 which is at Category 2). Recall that prehash modes always require both preimage and collision security from the message hash.

NIST IR 8547 and SP 800-131A Rev. 3 transition drafts suggest sunsetting the entire 112-bit "triple DES" security category -- depreciating or disallowing it from 2031. I wouldn't think that NIST would want to encourage its implementation at this point by providing algorithm certificates.

Cheers,
-markku

[niux_d...@icloud.com]

Hi Chris.

I've tested all other cases, including intrusively injecting message into my internal routine (both full message and external mu cases), and only the ones with non-deterministic "rnd" values fail.

I've examined the code path taken during and after my internal routine obtains randomness (including the case where it receive it from the prompts) - considering that no deviation exist in hedged version from the deterministic version, and that the deterministic version is correct, I think it is very likely that your code is receiving true randomness rather than the one from the prompt.

Can you check it out?

DannyNiu/NJF.

[Markku-Juhani O. Saarinen]

Hi Danny & Chris,

The non-deterministic cases don't work for me either -- previously (with the "internal" test vectors) they did.

I remember that ACVP code previously had a "fake RBG" hack around providing the randomness rather than an actual function argument for that. I don't have visibility to your code but that would be the first thing to check. One thing to do would be to make this new code visible (as a branch in the https://github.com/usnistgov/ACVP-Server ) so that we could see for sure if problems are caused by the test vector generator code.

If we ignore the non-deterministic cases, I have been able to pass most of the of the new test cases for ML-DSA, HashML-DSA (all provided hashes, even the "disallowed" 224-bit ones), and the external mu computation stuff as well. So OID encodings and are probably ok, and all three signing interfaces roughly work.

Some of the test cases don't really make sense to me -- for example there are cases with "internal" signature interface, yet with externalMu specified. What does that mean?

      "tgId": 7,

      "testType": "AFT",
      "parameterSet": "ML-DSA-44",
      "deterministic": false,
      "signatureInterface": "internal",
      "externalMu": true,

..

Cheers,

-markku

[niux_d...@icloud.com]

The externalMu option has to do with line 6 and 7 of Algorithm 7 ML-DSA.Sign_internal from FIPS-204 - NIST intends to allow the message representation (i.e. mu) to be computed externally.

Hence externalMu. Hope that helps Markku.

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/8abc10f9-ce39-4614-8aef-80cfeb5da185n%40list.nist.gov.

[Kris Kwiatkowski]

Hello,

Non-deterministic tests don't work for me as well.

Additionally, small nit - looking at registration.json it seems "preHash" capability it
should have exactly 2 options:

"preHash": [

"pure",

"preHash"

],

But some KATs set preHash to third value "none", i.e.

"tgId": 20,

"testType": "AFT",

"parameterSet": "ML-DSA-87",

"deterministic": true,

"signatureInterface": "internal",

"preHash": "none",

"externalMu": false,

"tests": [

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/8abc10f9-ce39-4614-8aef-80cfeb5da185n%40list.nist.gov.

[niux_d...@icloud.com]

Bit of chatty stuff.

In my library, DRBG is a class with a working context data type and some functions for seeding and generating bytes.

I've implemented CTR-DRBG and HMAC-DRBG (Hash-DRBG cannot work with SHA-3 so I omitted them). In an effort at CFRG in IETF, we were drafting a hedged version of ECDSA to use HMAC-DRBG, and it's suggested that KMAC can replace HMAC if SHA3 or SHAKE is used as hash function.

I was able to easily test randomness inputs, by using "FixedPRNG" - their working context is just a hex string; they've no seeding function, only generating functions which just does hex-to-byte conversion.

2024年11月26日 22:28，Markku-Juhani O. Saarinen <mjos....@gmail.com> 写道：

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/8abc10f9-ce39-4614-8aef-80cfeb5da185n%40list.nist.gov.

[Markku-Juhani O. Saarinen]

On Tue, Nov 26, 2024 at 4:38 PM <niux_d...@icloud.com> wrote:

The externalMu option has to do with line 6 and 7 of Algorithm 7 ML-DSA.Sign_internal from FIPS-204 - NIST intends to allow the message representation (i.e. mu) to be computed externally.

Hence externalMu. Hope that helps Markku.

Internal is the opposite of external.

Some of the test cases explicitly states that the interface is "internal", yet an external mu is provided. This is the thing that doesn't make sense.

Cheers,

-mar

[Celi, Christopher T. (Fed)]

Thank you. Output was too large for my IDE. I will update this when we go to CSRC ideally next week.

 

All OIDs are defined, and you can find them in the external-interface-intermediate-values.txt file.

 

Thanks,

Chris

[Celi, Christopher T. (Fed)]

Correct. I set the hash security strength filter too low on ML-DSA-44. It should be correct for the others. Just ignore those test cases, and this will be fixed when we go to CSRC.

 

FIPS 204 does state that hash functions that provide less than lambda security strength for collision resistance and second pre-image resistance are not allowed to be used. This sets the lower bound for ML-DSA-44 at SHA2-256 or stronger.

 

Thanks,

Chris

 

--

You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/55bf022c-5547-422e-94c3-e46d75acadefn%40list.nist.gov.

[Celi, Christopher T. (Fed)]

When externalMu is specified, you provide it to something running the internal interface because it is assumed that the external portion would be taken care of by the entity computing mu.

 

I will look at the non-deterministic aspect of the test vectors. I appreciate the active community here. It has passed all of our regression tests so I’m guessing it is something more around the construction of the JSON than the cryptography itself. I will likely not have something for you all this week given the holiday in the US.

 

Thanks,
Chris

 

From: Markku-Juhani O. Saarinen <mjos....@gmail.com>
Date: Tuesday, November 26, 2024 at 9:28 

AM

[Celi, Christopher T. (Fed)]

Thanks. This would mean preHash is not relevant, but we should be excluding the property entirely in that case.

 

Thanks,

Chris

 

From: pqc-...@list.nist.gov <pqc-...@list.nist.gov> on behalf of Kris Kwiatkowski <kr...@amongbytes.com>
Date: Tuesday, November 26, 2024 at 9:42 AM
To: pqc-forum <pqc-...@list.nist.gov>
Subject: Re: [pqc-forum] External Interface Testing for ML-DSA

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/db56cc49-2733-496c-b5b0-68ba403ce6c3%40amongbytes.com.

[niux_d...@icloud.com]

Hi Markku!

I'm just wondering if you're interested in verifying hedged signing unofficially with me.

I've generated a set of test values for the external routine (since you said that externalMu thing with internal routines' confusing).

Attached is the "internal projection" json I've generated. If there's news, please let me know.

Thanks. DannyNiu/NJF.

[Wei-Jun Wang]

On Nov 26, 2024, at 13:12, 'Celi, Christopher T. (Fed)' via pqc-forum <pqc-...@list.nist.gov> wrote:

I will look at the non-deterministic aspect of the test vectors.

Do we have new test vectors now?

Thanks,

Weijun

[Stony Flavor]

I known so

Flavor

--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/41A23FB1-B27F-4CF7-8E61-26D764FCBC36%40oracle.com.

[nis...@di-mgt.com.au]

Danny, I agree with all your test vectors you posted here.