Internet-Draft ACVP ML-DSA December 2025
Celi Expires 4 June 2026 [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 4 June 2026.

▲

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.

This document is a work-product of the NIST Cryptographic Algorithm Validation Program (CAVP). Please communicate questions and feedback concerning this document to the CAVP by opening an issue on the usnistgov/ACVP GitHub repository at https://github.com/usnistgov/ACVP/issues.

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, minimum, 15 tests generated for each combination of capabilities.

The second assurance is correctness under all rejection paths. Within ML-DSA sigGen, i.e., in Algorithm 7 ML-DSA.Sign_internal(), 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 Algorithm 7 ML-DSA.Sign_internal() [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, Algorithm 7 ML-DSA.Sign_internal(). 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 Algorithm 7 ML-DSA.Sign_internal() Known Answer Tests for Rejection Cases
Security Level Seed Key Hash M' 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 464756A9 85E5DF03 739D95DD 309C1ED9 C5B04254 CC294E7E 7EB9B936 5EE15117 AE95EA0D AA80199E 7B4A74EB 5A1B1DC6 C3805BD0 1D2FA78D 7C4FBA8C 255AA13D 491101BB A044DE6E 44A63796 C33CDA05 1BB05A60 725B87AF 4BA9DB94 0C03AC09 8E08EA0C 8DB94168 5B9905A7 3B0B57BA D3500B1F 73490480 B24375B4 1230CC04
ML-DSA-65 235A48DB 4CA7916B 884F424A 8586EFD5 17E87C64 AECEC0FC E9A3CC21 2BA1522E 1AC58A90 9DB4D7BC 2473AB5E 24AF7682 79C76F86 A82D4482 58E24EEA 4EA6B713 F8CE85CB 2EC474FF BF5A3FFA E029CE6F 4526B8D5 97655067 F97F438B 81071E9B AE9531A0 1738615B 6D33C77B 3FF618A8 6E101FDC 4C850468 1F0EDFA6 4511AD63
ML-DSA-65 E13131B7 05A76030 5FEFFEBF E99082E2 691A444B BEFCC3ED F67D9098 86200207 B422093F 95CC489C 52F4FA2B 8973A2FD DD44426D 1D04D1AA EEFC8715 D417181F CD365512 C7E61BBA A130800B 37F3BB46 AAF1BEEF 3742EA8A 9010A6DD 4576ED0B 3C55E604 DECA7B89 A99305D7 A391C35F 66A17C19 23F46767 5EC951C0 948D21C9
ML-DSA-65 0A4793E0 40A4BC0D 0F37643D 12C1EA1F 10648724 609936C7 6E0EC83E 37209E92 622D26D5 36D4D66C D94956B3 3A74E2E8 30ED265D 25C34FF7 C3E52434 03146ADF 6D9C7A79 5E48D80A 892CBF4D 45584297 87277E38 06EB5D0B CE1640EE BBBF9AEC 3B141110 B9F56540 B2D49AAC DE639997 4A4EAC40 621E367E 68D4504F 294DB21B
ML-DSA-65 F865B889 E5022D54 BABC81CA 67E7EB39 F1AC42F9 2CF5295C 3DA5C966 7DB1B924 45BC8EDD 1A620C46 E973E346 84427072 1824D978 88BC1742 81852D98 B7E8F4A3 047AFAAD BE020ED2 D766DA85 317DEDE8 0BE55054 5F0B21E3 F555A990 F8004258 56308A35 78360C41 356BA9C9 7D3240E0 1767FA76 BBBA9FD0 CC6CFA9A DD088DB9
ML-DSA-87 0D582191 32746BE0 77DFE821 E9F8FD87 857B28AB 91D6A567 E312A73E 2636032C 4D261270 341A7AC6 B66900DD C2B8AB34 AB483C89 7410DDF3 B2C072BD DA416434 3AA49EF7 2D010AEC 19383BA1 E83EC2DD 3DCC207A 96FFCEB9 FFA269E3 E3D66400 5049DC39 045618B9 03C71595 B3A3E07A 731F95D3 7304623A CC98BCEF 4258B4CA
ML-DSA-87 146C47AB 9F88408E B76A8132 94D533B2 9D7E0FDA 75DA5A4E 7C69EB61 EFEEBB78 05194438 AF855B79 DB8CCCCB 647D6BA5 C7AAF901 BBD09D3B 29395F0E A431D164 82C44F99 8A8D24F0 56084D0E 80ECFD84 34493385 A284C699 74923C27 0D397782 CFFC5988 A351E14A 3EE1282F 042A1436 79C45038 14296B27 993949A7 FF966F57
ML-DSA-87 049D9B0B 646A2AC7 F50B63CE 5E4BFE44 C9B87634 F4FF6C14 C513E388 B8A1F808 AC8FE6B2 FE26591B 129EA536 A9A001C7 85D8ACBD D9489F6E 51469A15 6E9E635D FEBC9F8A E159002B E1A11D39 5959DD7F C2071813 5690CDAA 2BCFB580 1C02AB89 FF400608 9BDF7337 E868F86D DF48F239 D2A52EA1 D0F686E0 103BF19C 3B571DB1
ML-DSA-87 9823DDDE 446A8EA8 83DAD3AC 6477F798 39FDC2D2 DEF2416B E0A8B71C FBC3F5C6 525010E3 07C4EA76 67D54EE2 7007C219 B01F4CF8 8DC3AB2D E8E9AAA5 9440A884 F7592C97 C1A96A2F 4053588F 5CDAD4C5 0BF7C375 2709854F A27779B4 45DD2BA2 FD775760 2B83B0A6 7A314CD5 BCC880E7 AE47ACDF 4D6AF982 69028EFB 486838F7
ML-DSA-87 AE213FE8 589B414F 53780D8B 9B683717 9967E13C B474C5AD 365C0437 78D2BC90 D4988E91 064E5DF6 D867434D 1DED16DC D8533E39 E420DC2B 4EB9E40A 84146F7D 19C1913B A76FF045 96BB7CC8 0FD825A5 AEDEF5D5 AD61CEDB 5203E6D7 EDB18877 23FE743E DD101970 D499E7EB 57A7AA24 5BAF417E 851B260C 55DD525A 445F08DA
Table 2: ML-DSA Algorithm 7 ML-DSA.Sign_internal() Known Answer Tests for Number of Rejection Cases
Security Level Rejection Count Seed Key Hash M' 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 64 26B605C7 8AC762FA 1634C6F9 1DD117C4 FBFF7F3A 7E7781F0 CC83B628 1F04AD7F 5DA13E57 1DF80867 A8F27E0F F81BE725 2A1ABF89 B3D6A03D 4036AF64 3EFBB04B C9B07E7D DC027446 8F312F5C 692A54AC 73D1E34D 8638E20A 2CD3C788 F27D4355 12A4637E 3A833A5A 2A46F6A9 91399E54 4B62A230 B7AA82F7 366840FF 6A88DE61
ML-DSA-65 73 9191CF38 1BEE1747 5C011986 EFB6AFB1 EFA69974 42FD3342 7353F1DA 1AA39FC0 7930D4E5 2BA03B61 DAA57743 B39E291D 824DC156 356C6B1A 8232574D 5C8BDD08 E616E36E 81AA1EC3 92621094 21AE0DDD A5E3B5A8 F4A252BC A27AE882 538DF618 3D758ACE 312433D7 80403B3D 4273171F B93D008B 39535214 2C6DC517 3E517310
ML-DSA-65 66 516912C7 B90A3DBE 009B7478 DBCAF0F5 C5C9ED96 99A20D0C A56CC516 E5A444CD 0FD15951 B93A4D19 446B48D4 7D32D2CA 2253FF43 BB8CCCB3 4C07E5F1 A3181B7A 9247CA75 F9456226 A0C783DA BCC33FF5 B4B48957 5ADED543 E74B29B4 5F9C8EF2 E5CE2678 00EDF335 88451050 F9B4A5BF 97030D04 5132A7E3 ED9210E7 4028D23B
ML-DSA-65 65 D4B841F8 82D50AB9 E590066B AFABA0F0 D04D3264 1C0B978E 54CCAA69 A6E8D2C4 0039C128 DDE6923E A08FF14F 5C5C66DC B282B471 FD1917DB EBE07C8C 45B73F8A 17523165 7B0F3C70 65947999 467C3420 64F29BFA EB553E97 561407D5 560E3AEB 8830EA25 4AF2854B F67C2B90 7E2321C9 4FD6EFB2 FDAA7766 9FC3A5C4 426C57C9
ML-DSA-65 64 5492EB8D 811072C0 30A30CC6 6B23A173 059EBA0D 4868CCB9 2FBE2510 B4A5915F 573DCD99 C86DAE81 F6F80CB0 0AF40846 028EA8F9 FE63102F E4A78238 BC7B660E 33D2753E D87D0003 B44C1AF5 F72EB931 F559C6B4 931AF7E2 49F65D3F A7613295 84D4AF50 933D6E13 D4332B86 AF0692A6 6F5030AB 01C2EAC4 131A5EEB F78CE9E5
ML-DSA-87 64 B5C07ECE FE9E7C3B 885FDEF0 32BDF9F8 07B4011E 2DFE6806 C088D208 1631C8EB 5D22F4C4 0F6EEB96 BB891DB1 5884ED4B 0009EA02 A24D9D1E 9ADFC81C 7A42EA7F D1D5C2D1 67D6E629 06790A5F EDF5A0A7 54CFAF47 E6A11AEB 93FB8C41 934C31F8 54F0A9CB 26F98B39 4A35918E CA6760EB D10753FC 5CDBA8BE 508873AD 83538131
ML-DSA-87 65 E8FC3C9F AD711DDA 2946334F BBD33146 8D6E9AB4 8EB86DCD 03F300A1 7AEBC5E5 B6C4DC9B 20CE5D0F 445931EE 316CF067 6E806D1A 6A988688 81D060EA 27CEB139 3B435F7A 2CE431C7 AB8EAE09 91C5DAC6 10827C99 D2780304 6FBC6C56 7D6B71F2 E337495F 08773F14 FB26A3E2 29B9B26D 086644C7 FDC30026 7F9DCDD5 D78DB849
ML-DSA-87 64 151F8088 6D6CE8C3 B428964F E02C40CA 0C8EFFA1 00EE089E 54D78534 4FCCF719 127972C3 3323FEFB F6B69C19 E0C86F41 558D9AB2 B1A8AD6F 39BD0A02 45DC8D7E C628CE94 D2AA99AA 50CF15B1 47D4F9A9 C62A3D46 12152DE0 A502C377 F472D614 99B552B2 14325442 48BFF47A C8F24CB7 8DBB25C9 683F3ADC B75614BE D58A0358
ML-DSA-87 64 48BEFFB4 C97E59E4 74E1906F 39888BE5 AE62F6A0 11C05EF6 A6B8D1E5 4F2171B7 72DA77CF 563CBB53 0129F601 29AF989C A4036BA1 058267BF BA34A2C7 0BE803C4 D2756A8F B4E47F79 6AF704ED 0FC8C6E5 73D42DFA B443B329 F00F8DB2 FF12C465 E643914B 8556D053 60C65EB3 E7A06BE7 C398B82D 49973EEF DC711E65 B11EB5E8
ML-DSA-87 69 FE2DA9DD 93A077FC B6452AC8 8D0A5762 EB896BAA AC6CE7D0 1CB1370B A8322390 7422DBE3 F476FFE4 1A4EFB33 F3DDFD8B 328029BA 30506038 66C36CFB C2EE4B87 A86B29AD F2300D26 36E21D4A 350CD18E 55A25437 9C3659A7 A95D8734 CEC1F005 8D25818D D972FFF5 B9E9B4CC 534A9510 0A1340C1 C81D1486 A68939D3 40E0A58B

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, minimum, 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)