Internet-Draft ACVP ML-DSA February 2025
Celi Expires 25 August 2025 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-celi-acvp-ml-dsa-01
:
Published:
Intended Status:
Informational
Expires:
Author:
C. Celi, Ed.

ACVP ML-DSA JSON Specification

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 25 August 2025.

▲

Table of Contents

1. Acknowledgements

There are no acknowledgements.

2. Abstract

This document defines the JSON schema for testing Module Lattice-based Digital Signature Algorithm (ML-DSA) implementations with the ACVP specification.

3. Introduction

The Automated Crypto Validation Protocol (ACVP) defines a mechanism to automatically verify the cryptographic implementation of a software or hardware crypto module. The ACVP specification defines how a crypto module communicates with an ACVP server, including crypto capabilities negotiation, session management, authentication, vector processing and more. The ACVP specification does not define algorithm specific JSON constructs for performing the crypto validation. A series of ACVP sub-specifications define the constructs for testing individual crypto algorithms. Each sub-specification addresses a specific class of crypto algorithms. This sub-specification defines the JSON constructs for testing Module Lattice-based Digital Signature Algorithm (ML-DSA) implementations using ACVP.

4. Conventions

4.1. Notation conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 of [RFC2119] and [RFC8174] when, and only when, they appear in all capitals, as shown here.

4.2. Terms and Definitions

4.2.1. Prompt

JSON sent from the server to the client describing the tests the client performs

4.2.2. Registration

The initial request from the client to the server describing the capabilities of one or several algorithm, mode and revision combinations

4.2.3. Response

JSON sent from the client to the server in response to the prompt

4.2.4. Test Case

An individual unit of work within a prompt or response

4.2.5. Test Group

A collection of test cases that share similar properties within a prompt or response

4.2.6. Test Vector Set

A collection of test groups under a specific algorithm, mode, and revision

4.2.7. Validation

JSON sent from the server to the client that specifies the correctness of the response

5. Supported ML-DSA Algorithms

The following ML-DSA algorithms MAY be advertised by the ACVP compliant cryptographic module. The list is in the form "algorithm / mode / revision".

6. Test Types and Test Coverage

6.1. Test Types

The ACVP server performs a set of tests on the specified ML-DSA algorithm in order to assess the correctness and robustness of the implementation. A typical ACVP validation session SHALL require multiple tests to be performed for every supported permutation of ML-DSA capabilities. This section describes the design of the tests used to validate implementations of the ML-DSA algorithms. The number of tests MAY vary but the minimum number required by each test type SHALL be included by the server. The test type describes the format of the test rather than the intention of the test. Multiple tests of the same test type MAY cover different assurances regarding the implementation.

6.1.1. ML-DSA KeyGen Test Types

  • ML-DSA / keyGen / * "AFT" - Algorithm Functional Test.

For each test case provided, the IUT SHALL generate a key pair from a provided seed. The key pair is communicated to the ACVP server and compared against the key pair generated by the server. This tests the implementation of Algorithm 6 ML-DSA.KeyGen_internal() from [FIPS204]. The server SHALL provide at least 25 tests for each combination of capabilities.

6.1.2. ML-DSA SigGen Test Types

  • ML-DSA / sigGen / * "AFT" - Algorithm Functional Test.

The IUT SHALL generate valid signatures based on the ACVP-provided message, mu (for external mu testing), private key, context (for external interface testing), hashAlg (for preHash testing), and randomness (for non-deterministic signature testing). The signature is then compared to the known signature by the ACVP server. This tests the implementation of Algorithm 2 ML-DSA.Sign(), Algorithm 4 HashML-DSA.Sign(), and Algorithm 7 ML-DSA.Sign_internal() from [FIPS204].

There are several assurances to obtain from AFTs. First is correctness of the algorithm implementation. The server SHALL include at least 15 tests for each combination of capabilities to meet this assurance. The "hashAlg" capability MAY be excluded from the combination of capabilities due to the number of supported hash functions. Each "hashAlg" provided by the IUT SHALL be covered within the at least 15 tests generated for each combination of capabilities.

The second assurance is correctness under all rejection paths. Within ML-DSA sigGen, the algorithm enters a loop until a valid signature is found. The loop contains four potential reasons to reject a candidate signature: if the z infinity norm is too large, if the r infinity norm is too large, if there are too many hints in h, or if the ct0 infinity norm is too large. These conditions occur at various rarities that can make it difficult to test each error condition with randomized testing. If an implementation adheres strictly to the pseudocode in [FIPS204], the following table provides helpful known answer tests that trigger each rejection case exactly once. If the implementation varies from the psuedocode, it would be prudent to use a debugger or other tooling to ensure that all rejection cases are triggered by testing. To save on space, the table will provide the seed used to generate the key pair, a hash of the keys, SHA2-256(pk || sk), and a hash of the resulting signature, SHA2-256(sig). All cases are defined using the deterministic signature method. Note that the ct0 infinity norm check only applies to ML-DSA-44. This condition is not possible on the other security levels. Thanks to Qinglai Xiao and Mike Hamburg (Rambus Inc) for providing code to generate these test cases; more information on their technique is available on the NIST PQC-Forum [PQCForum].

The server SHALL include at least 5 tests that cover all rejection outcomes for all combinations of capabilities where "signatureInterface" = "internal" and "deterministic" = true. The internal signature interface is described in [FIPS204] Algorithm 7 ML-DSA.Sign_internal() must be used to test this assurance. The Table 1 provides valid test cases for this assurance.

The third assurance is correctness under a large number of rejections. The standard, [FIPS204], does not define an upper limit on the number of potential rejections. Implementations that abort early may leak information about the underlying key. The server SHALL include at least 5 tests that lead to at least 32 rejections where "signatureInterface" = "internal" and "deterministic" = true. The internal signature interface described in [FIPS204] Algorithm 7 ML-DSA.Sign_internal() must be used to test this assurance. The Table 2 provides valid test cases for this assurance.

Table 1: ML-DSA sigGen Known Answer Tests for Rejection Cases
Security Level Seed Key Hash Message Signature Hash
ML-DSA-44 5C624FCC 18624524 52D0C665 840D8237 F43108E5 499EDCDC 108FBC49 D596E4B7 AC825C59 D8A4C453 A2C4EFEA 8395741C A404F300 0E28D56B 25D03BB4 02E5CB2F 951FDF54 73A4CBA6 D9E5B5DB 7E79FB81 73921BA5 B13E9271 401B8F90 7B8B7D5B DCC71A42 1BC6FFAF B7DF0C7F 6D018A19 ADA154D1 E2EE360E D533CECD 5DC980AD
ML-DSA-44 836EABED B4D2CD9B E6A4D957 CF5EE6BF 48930413 6864C55C 2C5F01DA 5047D18B E1FF40D9 6E3552FA B531D171 5084B7E3 8CCDBACC 0A8AF94C 30959FB4 C7F5A445 199A0AB7 35E90041 63DD02D3 19A61CFE 81638E3B F47BB1E9 0E90D6E3 EA545247 A2608BC2 7E60541D 27B6A14F 460D54A4 8C0298DC C3F45999 F29047A3 135C4941
ML-DSA-44 CA5A01E1 EA6552CB 5C980346 2B94C2F1 DC9D13BB 17A6ACE5 10D15705 6A2C6114 A4652DC4 A2710952 68DD84A5 B0744DFD BE2E642E 4D41FBC4 329C2FBA 534C0E13 8C8CACA8 8FFF52B9 33051053 7B3701B3 993F3726 136A650F 48F86045 51550832 B4B14220 9137397D AD504CAE D01D390A DAF49973 D8D2414F C3457FB7 AF775189
ML-DSA-44 9C005F15 50B4F318 55C6B92F 97873673 3F37791C B39DD182 D7BA5732 BDC2483E 2485AA99 345F1B33 4D4D94B6 10FBFFCC B626CBFD 4E9FF0E1 F6FC3509 3C423544 B744343F 30F7FEE0 88998BA5 74E799F1 BF3939C0 6C29BF9A C10F3588 A57E21E2 5B80A60B AA480B9D 0C7D2C05 B50928C4 BF6808DD A6936420 58A3EB77 EAA768FC
ML-DSA-44 4FAB5485 B009399E 8AE6FC3D 3EEFBFE8 E09796E4 477AABD5 EB1CC908 FA734DE3 CB56909A 7CF3008A 662DC635 EDCB79DC 151CA7AC BAE17B54 4384ABD9 1BBBC1E9 7CAB0FDC F4BEA5F0 39137478 AA45C9C4 8EF96D90 6FC49F6E 2F138111 BF1B4A4E 6CC38D73 D639682A BC556DC6 DCF436DE 24033091 F34004F4 10FABC68 87F77AB0
ML-DSA-65 CCD61917 2D0978FD B584D433 CB5A044C 8D24592D AD4D1E57 ECF1FD62 C40A309B 756C734D B013F83E 295F2878 B32F1633 5D576249 B16D83AF EDE1F5D4 CC36D24F 8A32D4B5 D3C8537A A9C7C952 F63959C6 6162A68D 5F3D02E6 C5F96E2C EA41D2EF 958287F1 646D855B B065895A 6C6DA3DF 6A3F7AB2 A430C9DC 559D313E 7DD0A527
ML-DSA-65 C6315FC7 19895D16 454B7D62 084F0C8A 2903D8D0 0DC1D82E B3F45F06 463C6FBD CEE1A1C7 F966A411 BB94C38A 0E33E1F7 102D3130 FA9C5D27 96F3F7F8 6ECF4B1D D8CB8B23 931495FD F71477DB 7C335A15 1C6A9096 97F1C39A 3175133B 68881F28 BD57A932 31EFEF6B 4E7FE374 E2194DB7 E00202EA F5EFC60D F5F9FE1C 5F579D06
ML-DSA-65 F005E473 8B528F95 3669A2BC A3925266 DBD23909 CD2C4DCE 50B980D7 89EBD0D4 D3E33502 CCC035C9 B9195A27 14FE7ECE DD13DFF4 B854F237 6D993D38 A8E8AFF2 EF1FE025 F8DF1FDC FDAFD188 F68B9D10 85AE8D09 234EBDAD 67DE985B A7347DE4 9E7B668C 51B250B1 2ED76665 BB4315CE 4BDBAF00 BF927F6D 895F0601 0D3BBC0E
ML-DSA-65 F215BA22 80D86F14 2012FC05 FFC04F2C 7D22FF5D D7D69AA0 EFB081E3 A53E9318 17FBD1D1 7DAACEA7 A2F6DA1F 22835E86 30E8AE8E F1A66E8B 7935CC6C C762532D A4FADC3C 232F2ABC 8FCBB9C1 11F261E0 3DC2FF2D 57280A42 42936A63 E481AFE6 C027D21B 21FA75AB E7F35CD8 4A54E2E8 3BD35214 0BC8C49E AB2C4500 4E7268A7
ML-DSA-65 A8E6C084 B3AAE469 0724631C AA57C10D F5973F95 38D25493 E264A4E2 B2C5A4E9 D8B7DE2D A326EBAE 241D657E C090F4CA 3438DFFE ECE1BD05 D9CE7DFC 5204C6DC A45A91B6 B2B392B7 087152D2 3E57E39A A78A42AB 91AAD034 4FB80393 F22FB0AE C9DB2B64 2F739B32 ED5B14B8 FEEE6C77 9BAE7297 17D4FF11 CA281954 D8FF1B1D
ML-DSA-87 5AC68A41 71730B1E 920CC3E7 CC4ACA79 C25A3621 0057373B 6BCEBCDF A144CE18 2446AB05 EEC3977C 40650338 983EEBF7 8942AC31 F5E94454 3E87DBAC 0A4889C1 172F6D49 AF757918 823A75E9 81D605DD AF74BF21 009AC836 D8B4C0AA BB49C14C 3784755A C5A2D572 0623E504 707C3088 61EF4177 A6460FBE B4DB257A AA245B55
ML-DSA-87 E45F9CC0 43C2C0F4 BEBCAD28 60CADF77 C8211237 D7AAA108 A56E3ACA 92D207F7 F5B727CA 02B6F302 5135926A 5FCA2A64 A800579C BFD44863 A08ABA5F E6C33B46 86B5A936 1F73427E BA3EEF5D 46112B74 67CEDFBC C77EF36C 94EF0666 C1AD37B6 E8276BF4 D57752D7 7C6EAE2B 80050ED2 0CF15344 B69E5150 F9479290 3EA3790A
ML-DSA-87 5E37A143 C0FFAEF6 00F33C37 6589069A 7A0CE2FA C36DBEFE C42C5A60 167D5A12 C210312C 242E0642 F990328A BFCD1189 D24EB8E9 C122BB6D FEFCF02D 4FCF6224 9A72DFEB 5CDAD43D 3A416F8A D7B6676D 5528DDDA 661C3513 B6A460DB 74331F51 B39E8111 5160026D A5528C40 B90EA146 64BFC22E 261023A7 DC419451 288ED93F
ML-DSA-87 51DF520B 9084E48B 72EAEBA7 FE36B540 05CD963B 58CC25DE 79339948 FD561065 3ECF7F6A 89387291 18CC21A1 5B2B5933 7B24FD34 38FB132D 0162E53C 28CB374C 28EFCAD1 C1B528E0 E46CB25D 28FA21DB A893010B 3C741D73 1460988B 66985D78 02FA4CF7 BF7F5BD1 3874C77B 30DAF708 BAA3E2C0 97D4298B F242A07B F68D7AD6
ML-DSA-87 6857AF5C 878EFF78 92F1722D 8CE11F47 84B9D144 B50B23B5 3070963B 501054E6 9A2B47D3 4624BA79 7ECE8C7C 67FAADB2 B2DA6C5C 802B3CFB 22D8167F 4B52D6EB 3165118C 135D81E4 6700B182 80A8D01D F39A4B1A 9C24748A EE3FC320 62DD251E 697E02D5 0185F96C 420015F1 C03A2DD4 64593E0A BD0493E0 99D8774B 26C30C2F
Table 2: ML-DSA sigGen Known Answer Tests for Number of Rejection Cases
Security Level Rejection Count Seed Key Hash Message Signature Hash
ML-DSA-44 77 090D97C1 F4166EB3 2CA67C5F B564ACBE 0735DB4A F4B8DB3A 7C2CE740 2357CA44 26D79E40 68040E99 6BC9EB50 34C20489 C0AD38DC 2FEC1918 D0760C86 21872408 E3838364 B37F47ED FCA2B577 B20B80C3 CB51B9F5 6E0E4CDB 7DF002C8 74039252 CD91150C 610FF02D E1DD7049 C309EFE8 00CE5C1B C2E5A32D 752AB62C 5BF5E16F
ML-DSA-44 100 CFC73D07 A883543A 804F7700 70861825 143A62F2 F97D05FC E00FD8B2 5D29A43F 89142AB2 6D6EB6C0 1FA3F189 A9C87759 7740D685 983F29BB DD359664 8266AE0E 0960C13E 9BA467A9 38450120 CC96FF6F 04B7E557 C99A8386 19A48F9A 38738AB8 B6296FFF 0C1F23DE 4906D581 44B00A2D B13AD25E 49B4B857 3A62EFEE CB544DD7
ML-DSA-65 111 111BDFD1 3CF30B4A 05F8C56E 91E20025 B284EFDC 661C349D 430FB988 149219EE C06FE457 14696FF2 C77BB4CD 96E70BE9 539117AC 3D2E3F77 C736B060 8D9E78B6 A30975C7 C58ABC8F E7FAE442 FE20F964 410B74E9 B4C1D47E 440223C5 A46DA72C CADA29AE EC8E59CD 70747C2E 4C83F963 7E3C2495 3F11ADEE F586F786 35B3E60A
ML-DSA-65 96 F3A3F2C3 263A7042 95E9D9F7 3CD97D02 F4682BEE 5949C416 BC42C85B 7C864446 997CEE99 5EECE252 8155E1AE 0095116C 6D97B150 8B76AD25 BAE4ADF6 B60AE6A2 1C00F3E4 CF07BD4F B797D683 76EEC537 01730C49 09EC404F C93A6B7F 597F81B5 006B205B FA8DFF6C 2AA4237A 6BB5A33D BD1B3D97 13B99A9D 5AF9A882 CD0BA1E0
ML-DSA-87 66 C4B614E8 3CF6E25A 159A542B 9E132AA0 68FACCD8 755AA8B4 E22C6F6C 0438BF16 5BCAD035 7C6F3911 68B00523 CD7B1333 5F95996B F5432545 5484B830 15925580 B9CFA245 C90359EF 041163A4 7231885E 56CB0215 984DE8A8 9941FE44 3CACEB61 5B23E5CE C5B09134 2EF7D5BB 8C50285A 9666CF93 7BBE1758 532B341B 0942994B
ML-DSA-87 77 771E9543 4E410291 93D076B8 06F2C3C2 2A7F2060 287791E7 0F105ECA EAB7AD69 C56A924B F6B046DA 3CACC10B 72749ECF 54266B38 A7E3D5C5 81D0A44F 1F3995D8 C367382D 0E3FEE86 D29BAB0E E5FD6AE9 1B3A5A70 17A024CF 145A25F5 6A62B0B1 4996F774 3E90DAEB 61B5FF86 A868C9E5 195F201C 4E5F5A75 F4C79031 AAA6C544

6.1.3. ML-DSA SigVer Test Types

  • ML-DSA / sigVer / * "AFT" - Algorithm Functional Test.

The IUT SHALL determine the validity of the signature based on the ACVP-provided message, mu (for external mu testing), context (for external interface testing), hashAlg (for preHash testing), public key, and signature. This tests the implementation of Algorithm 3 ML-DSA.Verify(), Algorithm 5 HashML-DSA.Verify(), and Algorithm 8 ML-DSA.Verify_internal() from [FIPS204]. Tests for signature verification are performed by the server modifying a valid signature to obtain specific assurances from the implementation. The server SHALL include at least 3 tests for each modification type (including "valid signature") for all combinations of capabilities. The "hashAlg" capability MAY be excluded from the combination of capabilities due to the number of supported hash functions. Each "hashAlg" provided by the IUT SHALL be covered within the at least 15 tests generated for each combination of capabilities.

The signature modifications are:

  • "valid signature and message - signature should verify successfully" - No modification is made and the signature is valid.
  • "modified message" - The message that was signed has been changed. The signature is not valid.
  • "modified signature - commitment" - A component of the signature, the bytes that commit the signer to the message, has been changed. The signature is not valid.
  • "modified signature - z" - A component of the signature, the bytes that allow the verifier to construct the vector z, has been changed. The signature is not valid.
  • "modified signature - hint" - A component of the signature, the bytes that allow the verifier to construct the hint array, has been changed. The signature is not valid.

6.2. Test Coverage

The tests described in this document have the intention of ensuring an implementation is conformant to [FIPS204].

6.2.1. Requirements Covered

  • The tests will ensure conformity and correctness of an implementation of the algorithms supported.

6.2.2. Requirements Not Covered

  • FIPS 204 Section 3.5. Additional Requirements. Requirements outlined in this section are not testable by an ACVP server. An ACVP server will not test the zeroization of intermediate values, security strength of the deterministic random bit generators (DRBGs), or incorrect length signatures or public keys.

7. Capabilities Registration

ACVP requires crypto modules to register their capabilities. This allows the crypto module to advertise support for specific algorithms, notifying the ACVP server which algorithms need test vectors generated for the validation process. This section describes the constructs for advertising support of ML-DSA algorithms to the ACVP server.

The algorithm capabilities MUST be advertised as JSON objects within the 'algorithms' value of the ACVP registration message. The 'algorithms' value is an array, where each array element is an individual JSON object defined in this section. The 'algorithms' value is part of the 'capability_exchange' element of the ACVP JSON registration message. See the ACVP specification [ACVP] for more details on the registration message.

7.1. Prerequisites

Each algorithm implementation MAY rely on other cryptographic primitives. For example, RSA Signature algorithms depend on an underlying hash function. Each of these underlying algorithm primitives must be validated, either separately or as part of the same submission. ACVP provides a mechanism for specifying the required prerequisites:

Prerequisites, if applicable, MUST be submitted in the registration as the prereqVals JSON property array inside each element of the algorithms array. Each element in the prereqVals array MUST contain the following properties

Table 3: Prerequisite Properties
JSON Property Description JSON Type
algorithm a prerequisite algorithm string
valValue algorithm validation number string

A "valValue" of "same" SHALL be used to indicate that the prerequisite is being met by a different algorithm in the capability exchange in the same registration.

An example description of prerequisites within a single algorithm capability exchange looks like this

"prereqVals":
[
  {
    "algorithm": "Alg1",
    "valValue": "Val-1234"
  },
  {
    "algorithm": "Alg2",
    "valValue": "same"
  }
]

7.2. Required Prerequisite Algorithms for ML-DSA Validations

Each ML-DSA implementation relies on other cryptographic primitives. For example, ML-DSA keyGen uses an underlying SHA algorithm. Each of these underlying algorithm primitives must be validated, either separately or as part of the same submission. ACVP provides a mechanism for specifying the required prerequisites:

Table 4: Required ML-DSA Prerequisite Algorithms JSON Values
JSON Value Description JSON Type Valid Values
algorithm a prerequisite algorithm string SHA, or DRBG
valValue algorithm validation number string Actual number or "same"
prereqAlgVal prerequisite algorithm validation object with algorithm and valValue properties See above

7.3. ML-DSA keyGen Registration Properties

Each ML-DSA keyGen algorithm capability advertised is a self-contained JSON object using the following values.

Table 5: ML-DSA keyGen Algorithm Capabilities JSON Values
JSON Value Description JSON Type Valid Values
algorithm The ML-DSA algorithm to be validated string "ML-DSA"
mode The ML-DSA mode to be validated string "keyGen"
revision The algorithm testing revision to use string "FIPS204"
prereqVals Prerequisite algorithm validations array of prereqAlgVal objects See Section 7.2
parameterSets The ML-DSA parameter sets supported array of strings "ML-DSA-44", "ML-DSA-65", "ML-DSA-87"

7.3.1. ML-DSA keyGen Mode Capabilities Example

Below is an example of the registration for ML-DSA / keyGen / FIPS204

{
    "algorithm": "ML-DSA",
    "mode": "keyGen",
    "revision": "FIPS204",
    "prereqVals": [
        {
            "algorithm": "SHA",
            "valValue": "123456"
        }
    ],
    "parameterSets": ["ML-DSA-44", "ML-DSA-65", "ML-DSA-87"]
}

7.4. ML-DSA sigGen Registration Properties

Each ML-DSA sigGen algorithm capability advertised is a self-contained JSON object using the following values.

Table 6: ML-DSA sigGen Algorithm Capabilities JSON Values
JSON Value Description JSON Type Valid Values
algorithm The ML-DSA algorithm to be validated string "ML-DSA"
mode The ML-DSA mode to be validated string "sigGen"
revision The algorithm testing revision to use string "FIPS204"
prereqVals Prerequisite algorithm validations array of prereqAlgVal objects See Section 7.2
capabilities An array of individual capability objects array of capability objects See Table 7
deterministic The ML-DSA signature generation modes supported array of booleans true, false
signatureInterfaces The ML-DSA signature interfaces supported array of strings "internal", "external"
preHash Whether ML-DSA and HashML-DSA are supported. Only required when "signatureInterfaces" contains "external". array of strings "pure", "preHash"
externalMu Whether mu is computed internally to the module or externally from the module under test. Only applicable when "signatureInterfaces" contains "internal". array of booleans true, false

The capability objects use the following properties.

Table 7: ML-DSA sigGen Capability Property JSON Values
JSON Value Description JSON Type Valid Values
parameterSets The ML-DSA parameter sets supported array of strings "ML-DSA-44", "ML-DSA-65", "ML-DSA-87"
messageLength The supported message lengths in bits domain Min: 8, Max: 65536, Incr: 8
hashAlgs The hash algorithms used if preHash ML-DSA is used array of strings "SHA2-224", "SHA2-256", "SHA2-384", "SHA2-512", "SHA2-512/224", "SHA2-512/256", "SHA3-224", "SHA3-256", "SHA3-384", "SHA3-512", "SHAKE-128", "SHAKE-256"
contextLength The supported context lengths if the external interface is used domain Min: 0, Max: 2040, Incr: 8

7.4.1. ML-DSA sigGen Mode Capabilities Example

Below is an example of the registration for ML-DSA / sigGen / FIPS204

{
  "algorithm": "ML-DSA",
  "mode": "sigGen",
  "revision": "FIPS204",
  "prereqVals": [
    {
      "algorithm": "SHA",
      "valValue": "123456"
    }
  ],
  "capabilities": [
    {
      "parameterSets": [
        "ML-DSA-44",
        "ML-DSA-65",
        "ML-DSA-87"
      ],
      "messageLength": [
        {
          "min": 8,
          "max": 65536,
          "increment": 8
        }
      ],
      "hashAlgs": [
        "SHA2-224",
        "SHA2-256",
        "SHA2-384",
        "SHA2-512",
        "SHA2-512/224",
        "SHA2-512/256",
        "SHA3-224",
        "SHA3-256",
        "SHA3-384",
        "SHA3-512",
        "SHAKE-128",
        "SHAKE-256"
      ],
      "contextLength": [
        {
          "min": 0,
          "max": 2040,
          "increment": 8
        }
      ]
    }
  ],
  "deterministic": [
    true,
    false
  ],
  "externalMu": [
    true,
    false
  ],
  "signatureInterfaces": [
    "external",
    "internal"
  ],
  "preHash": [
    "pure",
    "preHash"
  ]
}

7.5. ML-DSA sigVer Registration Properties

Each ML-DSA sigVer algorithm capability advertised is a self-contained JSON object using the following values.

Table 8: ML-DSA sigVer Algorithm Capabilities JSON Values
JSON Value Description JSON Type Valid Values
algorithm The ML-DSA algorithm to be validated string "ML-DSA"
mode The ML-DSA mode to be validated string "sigVer"
revision The algorithm testing revision to use string "FIPS204"
prereqVals Prerequisite algorithm validations array of prereqAlgVal objects See Section 7.2
capabilities An array of individual capability objects array of capability objects See Table 9
signatureInterfaces The ML-DSA signature interfaces supported array of strings "internal", "external"
preHash Whether ML-DSA and HashML-DSA are supported. Only required when "signatureInterfaces" contains "external". array of strings "pure", "preHash"
externalMu Whether mu is computed internally to the module or externally from the module under test. Only applicable when "signatureInterfaces" contains "internal". array of booleans true, false

The capability objects use the following properties.

Table 9: ML-DSA sigVer Capability Property JSON Values
JSON Value Description JSON Type Valid Values
parameterSets The ML-DSA parameter sets supported array of strings "ML-DSA-44", "ML-DSA-65", "ML-DSA-87"
messageLength The supported message lengths in bits domain Min: 8, Max: 65536, Incr: 8
hashAlgs The hash algorithms used if preHash ML-DSA is used array of strings "SHA2-224", "SHA2-256", "SHA2-384", "SHA2-512", "SHA2-512/224", "SHA2-512/256", "SHA3-224", "SHA3-256", "SHA3-384", "SHA3-512", "SHAKE-128", "SHAKE-256"
contextLength The supported context lengths if the external interface is used domain Min: 0, Max: 2040, Incr: 8

7.5.1. ML-DSA sigVer Mode Capabilities Example

Below is an example of the registration for ML-DSA / sigVer / FIPS204

{
  "algorithm": "ML-DSA",
  "mode": "sigVer",
  "revision": "FIPS204",
  "prereqVals": [
    {
      "algorithm": "SHA",
      "valValue": "123456"
    }
  ],
  "capabilities": [
    {
      "parameterSets": [
        "ML-DSA-44",
        "ML-DSA-65",
        "ML-DSA-87"
      ],
      "messageLength": [
        {
          "min": 8,
          "max": 65536,
          "increment": 8
        }
      ],
      "hashAlgs": [
        "SHA2-224",
        "SHA2-256",
        "SHA2-384",
        "SHA2-512",
        "SHA2-512/224",
        "SHA2-512/256",
        "SHA3-224",
        "SHA3-256",
        "SHA3-384",
        "SHA3-512",
        "SHAKE-128",
        "SHAKE-256"
      ],
      "contextLength": [
        {
          "min": 0,
          "max": 2040,
          "increment": 8
        }
      ]
    }
  ],
  "externalMu": [
    true,
    false
  ],
  "signatureInterfaces": [
    "external",
    "internal"
  ],
  "preHash": [
    "pure",
    "preHash"
  ]
}

8. Test Vectors

The ACVP server provides test vectors to the ACVP client, which are then processed and returned to the ACVP server for validation. A typical ACVP validation test session would require multiple test vector sets to be downloaded and processed by the ACVP client. Each test vector set represents an individual cryptographic algorithm defined during the capability exchange. This section describes the JSON schema for a test vector set used with Module Lattice-based Digital Signature Algorithm (ML-DSA) algorithms.

The test vector set JSON schema is a multi-level hierarchy that contains meta data for the entire vector set as well as individual test vectors to be processed by the ACVP client. The following table describes the JSON elements at the top level of the hierarchy.

Table 10: Top Level Test Vector JSON Elements
JSON Values Description JSON Type
acvVersion Protocol version identifier string
vsId Unique numeric vector set identifier integer
algorithm Algorithm defined in the capability exchange string
mode Mode defined in the capability exchange string
revision Protocol test revision selected string
testGroups Array of test group JSON objects. Depending on the algorithm, see Section 8.1.1, Section 8.2.1 or Section 8.3.1 array

An example of this would look like this

[
  {
    "acvVersion": <version>
  },
  {
    "vsId": 1,
    "algorithm": "Alg1",
    "mode": "Mode1",
    "revision": "Revision1.0",
    "testGroups": [ ... ]
  }
]

8.1. ML-DSA keyGen Test Vectors

8.1.1. ML-DSA keyGen Test Groups JSON Schema

The testGroups element at the top level in the test vector JSON object is an array of test groups. Test vectors are grouped into similar test cases to reduce the amount of data transmitted in the vector set. For instance, all test vectors that use the same key size would be grouped together. The Test Group JSON object contains meta data that applies to all test vectors within the group. The following table describes the ML-DSA JSON elements of the Test Group JSON object.

The test group for ML-DSA / keyGen / FIPS204 is as follows:

Table 11: ML-DSA keyGen Test Group JSON Object
JSON Value Description JSON type
tgId Numeric identifier for the test group, unique across the entire vector set integer
testType The test operation performed string
parameterSet The ML-DSA parameter set used string
tests Array of individual test vector JSON objects, which are defined in Section 8.1.2 array

8.1.2. ML-DSA keyGen Test Case JSON Schema

Each test group contains an array of one or more test cases. Each test case is a JSON object that represents a single test vector to be processed by the ACVP client. The following table describes the JSON elements for each ML-DSA test vector.

Table 12: ML-DSA keyGen Test Case JSON Object
JSON Value Description JSON type
tcId Numeric identifier for the test case, unique across the entire vector set integer
seed The seed used to generate the key pair hex

The following is an example JSON object sent from the server to the client for ML-DSA / keyGen / FIPS204.

[
    {
        "acvVersion": <acvp-version>
    },
    {
        "vsId": 1564,
        "algorithm": "ML-DSA",
        "mode": "keyGen",
        "revision": "FIPS204",
        "testGroups": [
            {
                "tgId": 1,
                "testType": "AFT",
                "parameterSet": "ML-DSA-44",
                "tests": [
                    {
                        "tcId": 1,
                        "seed": "C105DC2..."
                    }
                ]
            }
        ]
    }
]

8.2. ML-DSA sigGen Test Vectors

8.2.1. ML-DSA sigGen Test Groups JSON Schema

The testGroups element at the top level in the test vector JSON object is an array of test groups. Test vectors are grouped into similar test cases to reduce the amount of data transmitted in the vector set. For instance, all test vectors that use the same key size would be grouped together. The Test Group JSON object contains meta data that applies to all test vectors within the group. The following table describes the ML-DSA JSON elements of the Test Group JSON object.

The test group for ML-DSA / sigGen / FIPS204 is as follows:

Table 13: ML-DSA sigGen Test Group JSON Object
JSON Value Description JSON type
tgId Numeric identifier for the test group, unique across the entire vector set integer
testType The test operation performed string
parameterSet The ML-DSA parameter set used string
deterministic Whether the signatures should be generated using the deterministic or non-deterministic routine boolean
signatureInterface Whether the signature is generated using the internal or external routine string
preHash Whether the signature is generated using the prehash or pure routine string
externalMu Whether mu is computed internally or externally to the module under test string
tests Array of individual test vector JSON objects, which are defined in Section 8.2.2 array

8.2.2. ML-DSA sigGen Test Case JSON Schema

Each test group contains an array of one or more test cases. Each test case is a JSON object that represents a single test vector to be processed by the ACVP client. The following table describes the JSON elements for each ML-DSA test vector.

Table 14: ML-DSA sigGen Test Case JSON Object
JSON Value Description JSON type
tcId Numeric identifier for the test case, unique across the entire vector set integer
message The message used to generate the signature hex
mu The mu used to generate the signature hex
sk When the test group property "testType": "AFT", the secret key that should be used to generate a signature hex
rnd When the test group properties "testType": "AFT" and "deterministic": false, the random value used to generate the signature hex
context When the test group property "signatureInterface": "external", the context used to construct the signed message hex
hashAlg When the test group property "preHash": "preHash", the hash function used to construct the signed message string

The following is an example JSON object sent from the server to the client for ML-DSA / sigGen / FIPS204.

[
    {
        "acvVersion": <acvp-version>
    },
    {
        "vsId": 0,
        "algorithm": "ML-DSA",
        "mode": "sigGen",
        "revision": "FIPS204",
        "testGroups": [
            {
                "tgId": 1,
                "testType": "AFT",
                "parameterSet": "ML-DSA-44",
                "signatureInterface": "internal",
                "externalMu": false,
                "deterministic": true,
                "tests": [
                    {
                        "tcId": 1,
                        "sk": "D4E36A5...",
                        "message": "0D873AEFD..."
                    }
                ]
            },
            {
                "tgId": 2,
                "testType": "AFT",
                "parameterSet": "ML-DSA-44",
                "signatureInterface": "internal",
                "externalMu": true,
                "deterministic": false,
                "tests": [
                    {
                        "tcId": 71,
                        "sk": "D4E36A5...",
                        "mu": "34F4B...",
                        "rnd": "7AFF2F22A..."
                    }
                ]
            },
            {
                "tgId": 3,
                "testType": "AFT",
                "parameterSet": "ML-DSA-44",
                "signatureInterface": "external",
                "preHash": "pure",
                "deterministic": true,
                "tests": [
                    {
                        "tcId": 71,
                        "sk": "D4E36A5...",
                        "message": "34F4B...",
                        "context": "ABCD"
                    }
                ]
            },
            {
                "tgId": 4,
                "testType": "AFT",
                "parameterSet": "ML-DSA-44",
                "signatureInterface": "external",
                "preHash": "preHash",
                "deterministic": false,
                "tests": [
                    {
                        "tcId": 71,
                        "sk": "D4E36A5...",
                        "message": "34F4B...",
                        "rnd": "7AFF2F22A...",
                        "context": "ABCD",
                        "hashAlg": "SHA2-256"
                    }
                ]
            }
        ]
    }
]

8.3. ML-DSA sigVer Test Vectors

8.3.1. ML-DSA sigVer Test Groups JSON Schema

The testGroups element at the top level in the test vector JSON object is an array of test groups. Test vectors are grouped into similar test cases to reduce the amount of data transmitted in the vector set. For instance, all test vectors that use the same key size would be grouped together. The Test Group JSON object contains meta data that applies to all test vectors within the group. The following table describes the ML-DSA JSON elements of the Test Group JSON object.

The test group for ML-DSA / sigVer / FIPS204 is as follows:

Table 15: ML-DSA sigVer Test Group JSON Object
JSON Value Description JSON type
tgId Numeric identifier for the test group, unique across the entire vector set integer
testType The test operation performed string
parameterSet The ML-DSA parameter set used string
signatureInterface Whether the signature is generated using the internal or external routine string
preHash Whether the signature is generated using the prehash or pure routine string
tests Array of individual test vector JSON objects, which are defined in Section 8.3.2 array

8.3.2. ML-DSA sigVer Test Case JSON Schema

Each test group contains an array of one or more test cases. Each test case is a JSON object that represents a single test vector to be processed by the ACVP client. The following table describes the JSON elements for each ML-DSA test vector.

Table 16: ML-DSA sigVer Test Case JSON Object
JSON Value Description JSON type
tcId Numeric identifier for the test case, unique across the entire vector set integer
pk The public key used to verify the signature hex
message The message used to verify with the signature hex
mu The mu used to generate the signature hex
signature The signature to verify hex
context When the test group property "signatureInterface": "external", the context used to construct the signed message hex
hashAlg When the test group property "preHash": "preHash", the hash function used to construct the signed message string

The following is an example JSON object sent from the server to the client for ML-DSA / sigVer / FIPS204.

[
  {
    "acvVersion": <acvp-version>
  },
  {
    "vsId": 0,
    "algorithm": "ML-DSA",
    "mode": "sigVer",
    "revision": "FIPS204",
    "isSample": false,
    "testGroups": [
      {
        "tgId": 1,
        "testType": "AFT",
        "parameterSet": "ML-DSA-44",
        "signatureInterface": "internal",
        "externalMu": false,
        "tests": [
          {
            "tcId": 1,
            "pk": "3FE65294...",
            "message": "4F0D7...",
            "signature": "C29A11B6C..."
          },
          {
            "tcId": 2,
            "pk": "3FE65294...",
            "message": "84793...",
            "signature": "6A99215FC2..."
          }
        ]
      },
      {
        "tgId": 2,
        "testType": "AFT",
        "parameterSet": "ML-DSA-44",
        "signatureInterface": "internal",
        "externalMu": true,
        "tests": [
          {
            "tcId": 3,
            "pk": "3FE65294...",
            "mu": "4F0D7...",
            "signature": "C29A11B6C..."
          }
        ]
      },
      {
        "tgId": 3,
        "testType": "AFT",
        "parameterSet": "ML-DSA-44",
        "signatureInterface": "external",
        "preHash": "pure",
        "tests": [
          {
            "tcId": 4,
            "pk": "4C7029A9...",
            "message": "75E...",
            "context": "548...",
            "signature": "04D1B8..."
          },
        ]
      },
      {
        "tgId": 4,
        "testType": "AFT",
        "parameterSet": "ML-DSA-44",
        "signatureInterface": "external",
        "preHash": "preHash",
        "tests": [
          {
            "tcId": 5,
            "pk": "5FB42D9CF5EE...",
            "message": "8740606...",
            "context": "0710CE7...",
            "hashAlg": "SHA2-224",
            "signature": "C0D60..."
          }
        ]
      }
    ]
  }
]

9. Test Vector Responses

After the ACVP client downloads and processes a vector set, it must send the response vectors back to the ACVP server. The following table describes the JSON object that represents a vector set response.

Table 17: Response JSON Object
JSON Property Description JSON Type
acvVersion The ACVP version used string
vsId The vector set identifier integer
testGroups The test group objects in the response, see Table 18 array

An example of this is the following

{
    "acvVersion": "version",
    "vsId": 1,
    "testGroups": [ ... ]
}

The 'testGroups' section is used to organize the ACVP client response in a similar manner to how it distributes vectors.

Table 18: Response Group Objects
JSON Property Description JSON Type
tgId The test group identifier integer
tests The test case objects in the response, depending on the algorithm see Table 19, Table 20, or Table 21 array

An example of this is the following

{
    "tgId": 1,
    "tests": [ ... ]
}

9.1. ML-DSA keyGen Test Vector Responses

Each test group contains an array of one or more test cases. Each test case is a JSON object that represents a single test vector to be processed by the ACVP client. The following table describes the JSON elements for each ML-DSA / keyGen / FIPS204 test vector.

Table 19: ML-DSA keyGen Test Case Response JSON Object
JSON Value Description JSON type
tcId The test case identifier integer
pk The computed public key hex
sk The computed secret key hex

The following is an example JSON test vector response object for ML-DSA / keyGen / FIPS204.

[
    {
        "acvVersion": <acvp-version>
    },
    {
        "vsId": 0,
        "testGroups": [
            {
                "tgId": 1,
                "tests": [
                    {
                        "tcId": 1,
                        "pk": "1012798...",
                        "sk": "1012798..."
                    }
                ]
            }
        ]
    }
]

9.2. ML-DSA sigGen Test Vector Responses

Each test group contains an array of one or more test cases. Each test case is a JSON object that represents a single test vector to be processed by the ACVP client. The following table describes the JSON elements for each ML-DSA / sigGen / FIPS204 test vector.

Table 20: ML-DSA sigGen Test Case Response JSON Object
JSON Value Description JSON type
tcId The test case identifier integer
signature The generated signature hex

The following is an example JSON test vector response object for ML-DSA / sigGen / FIPS204.

[
    {
        "acvVersion": <acvp-version>
    },
    {
        "vsId": 1564,
        "testGroups": [
            {
                "tgId": 1,
                "tests": [
                    {
                        "tcId": 1,
                        "signature": "D7D4275..."
                    }
                ]
            }
        ]
    }
]

9.3. ML-DSA sigVer Test Vector Responses

Each test group contains an array of one or more test cases. Each test case is a JSON object that represents a single test vector to be processed by the ACVP client. The following table describes the JSON elements for each ML-DSA / sigVer / FIPS204 test vector.

Table 21: ML-DSA sigVer Test Case Response JSON Object
JSON Value Description JSON type
tcId The test case identifier integer
testPassed Whether or not the signature verified boolean

The following is an example JSON test vector response object for ML-DSA / sigVer / FIPS204.

[
    {
        "acvVersion": <acvp-version>
    },
    {
        "vsId": 0,
        "testGroups": [
            {
                "tgId": 1,
                "tests": [
                    {
                        "tcId": 1,
                        "testPassed": false
                    }
                ]
            }
        ]
    }
]

10. Security Considerations

There are no additional security considerations outside of those outlined in the ACVP document.

11. IANA Considerations

This document does not require any action by IANA.

12. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", RFC 8174, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[FIPS204]
NIST, "Module-Lattice-Based Digital Signature Standard", NIST FIPS 204, , <https://csrc.nist.gov/pubs/fips/204/final>.
[ACVP]
Fussell, B., Vassilev, A., and H. Booth, "Automatic Cryptographic Validation Protocol", ACVP, .
[PQCForum]
"PQC-Forum", PQCForum, <https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/G8Zf0hC-uu0/m/Kb3qNJb0AwAJ>.

Author's Address

Christopher Celi (editor)