Internet-Draft ACVP ML-DSA September 2024
Celi Expires 16 March 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 16 March 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.

  • ML-DSA / keyGen / * "AFT" - Algorithm Functional Test. The IUT is REQUIRED for each test case provided, to generate a key pair from a provided seed. The key pair is communicated to the ACVP server and validated. This tests the implementation of Algorithm 6 ML-DSA.KeyGen_internal() from [FIPS204] Section 6.1.
  • ML-DSA / sigGen / * "AFT" - Algorithm Functional Test. This testing mode expects the IUT to generate valid signatures based on the ACVP provided message. The signature is then compared to the known result by the ACVP server given the IUT's communicated parameter set, public key, and signature. This tests the implementation of Algorithm 7 ML-DSA.Sign_internal() from [FIPS204] Section 6.2.
  • ML-DSA / sigVer / * "AFT" - Algorithm Functional Test. The ACVP server generates a series of signatures to communicate to the IUT. The IUT is REQUIRED to determine the validity of the signature given the parameter set, key, and message. This tests the implementation of Algorithm 8 ML-DSA.Verify_internal() from [FIPS204] Section 6.3.

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.

6.3. Known Answer Tests

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 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, and a hash of the keys, SHA2-256(pk || sk). A hash of the resulting signature is also provided, 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].

Table 1: ML-DSA sigGen Known Answer Tests for Rejection Cases
Security Level Seed Key Hash Message Signature Hash
ML-DSA-44 9EFCCC4652FFCCA921675044212B9845A06591ED6C21BDAA7053F18788B8FAB8 F5721F9249EC740A32C8EDAD28DE5913587DD09509396BCC82466ED9D05C2422 636EF578FF26E7286BF9E6AA832FD1B3E2830C971571425AD3925197C9BDCF35 1379ACF5632268AAA4CD113BE8D2E99A886113CC577C7DB495E8FF2442781900
ML-DSA-44 B6D8DF653CB0AC358B8DCB5043CBD77DC75738CA9561460AF30C6827502D38B0 9FFE68221D549ABB63901348C811E2D4CC46AF33E90798F1E2EE6CFFDA6EFB6C D1CC972EBE55557C9BDFA211F509C76B9867FE08CE92AF4D9AE84ABD9471E280 1977159429814BC3054B5DFB912CA912FD779D1F4D706BC9D752E9E9248249F8
ML-DSA-44 19A4578402EA7A3B0FA1E6A642B346202F70FD48EFF88716700D2FB856F637E1 6C346DF3312E5F08AA6FD536B650B0000E875956E11DA641C2A09AE2C008D739 F6BA1E9EDBB1DD6C31D50E039EBB5D2E6BDD88EC74D415C55BF2BDF8119C1F99 9BF7310CBA86AA09655951746356BAEB3160928A472F0F800321A1102D513277
ML-DSA-44 19A4578402EA7A3B0FA1E6A642B346202F70FD48EFF88716700D2FB856F637E1 6C346DF3312E5F08AA6FD536B650B0000E875956E11DA641C2A09AE2C008D739 59334D1433CC317A4E0B20AB4C8695FE92384F094CFC4AB9E2731921CFE82E95 2BBF13A30DF7F20BB20469C0AA1A37207327E1AEC8DC0353426951F134C7F336
ML-DSA-44 D0CBB07234CF3DAC9ABCFEAD5F30D386503D74394FF2E89C572893623B352CE2 1725AF7435651074D115180AB3BD7045E3119AC7B01E329C667CABDBA7AF81A9 6A98B59552C3ABF1E12CE10214DEB33E266E83439674B1C62A8118CD299F4DDA FBFB9FDD9932B7ADCD6EB9C1988954F5523B50E400958B7E3E2FBD514D07B811
ML-DSA-44 AF3B137E678A32C9890DA57B908212B883DF5F53698906AC259DC957F3AA0F49 C592A44E6BA38F32ED2AD6020CFEF4762AEF29FE1E6B81B13F011B70B4B27878 E5E6CDA64A9BCDCE1B3CF60ED5FBD32067B007E99AE8D30BCBB3A47D6606BC63 D31400BA008C66C13CB82BF7C4EB98B4127B0D018A26B5F78B724E4816D0575B
ML-DSA-44 41F1DD6ADBE99B20F7C09CBEC35FE4D577121AB1A2D1F19A67D093A889A212BF 81C98CAEA0C96CDC7E6E899F3D21C65D5A1BA1ADBFB05709A3DD94760657481D DEFC0A181C7EEE47E366B775069E4E75E9B03E41A32FD992F5321F5F3ABF3A1E FC7835D7BC7A005DC9E80A331D24FEAB4A09F22269DA05D88F31114E65522CC0
ML-DSA-44 EDC15BAB40D4F0061A42BB1B1E25FB88DDA81DE556B5B7D1D1F6F976BF18D342 B48037915BEAF73FD8071C4A37D8650F9BDC43FF448CA5FC2A5D82128A5415E2 9AFE6CEC7BEBCE176F3BED99F6530B30235F9DCE8DB2B845ABC29DDC7800D0DF FF8D018D776DDBE437E10AFA01092F622E133BC968E6F3547B5EEC0582340BA2
ML-DSA-44 06DE27935B3546108CB5DF5B9D20962E66E9483D28B6BD3526BC29E67D639346 DEFF6103F2461EE3664598D047308DF594481D8A7909D665A39D9E3F7BFD378E 2BC53BCC9014351EBE53927437DC3B3445221D367060A7E02387F05D6AF88CDA 9B767458CC66B0CAC8CBB23688AE62A031AA0C0C1A2A94D05BCCE63F89F662DE
ML-DSA-44 0EB9FC82941492B544B335299F0A9988149B073481E524A463E0DCBB5CA6D0CD 3981CDAE116B3FBBD4FB5F84B62EF8B799E4859780063DE7CD7CD1FE1C95F12A 91A6C4DA9EFA41C589183A460BEB2BF717A63538AD677698C2F1FBFD4EE5FB03 1330509757042FF7CE5D370DAC53EFF645D387E9F9F59E26DA7CA47815C2BF59
ML-DSA-44 6CB6030AA76C4F4079FC0396664FF361B994697DB2FE9F182835CA0A93FE6B3B E77BF73434960A36BF59724E8B26370E7F84480563C0BDC75A5FAF2B47C0A59B 35C034A8D77CBD042FBC6F0083FA29374F7ADC8F66CCED0556F69D1814E4D453 EED5A78DC83D3F0DD6D2CD17765F3C71CBE3D2DD1C282A800577A3D88E5532B5
ML-DSA-44 96EC11B9D089E586E7686EE4A0D0EFD76E4B03D4A3BC1A1CC19E3E6D9B0B0932 6494B70209B2957B4F2FEFFD608F46F2EE230448055E85F27ACF7504DD52BD86 860036A45D331BCD28DEC06841233FCB73F6DD6515604C39F85FA790326F1C70 EEE85299E4C205D5833013B22AD21B459A241FC5F9FD97C5BAB33068B61F1459
ML-DSA-44 96EC11B9D089E586E7686EE4A0D0EFD76E4B03D4A3BC1A1CC19E3E6D9B0B0932 6494B70209B2957B4F2FEFFD608F46F2EE230448055E85F27ACF7504DD52BD86 EB9E8DD8C013FF6B35434544956D35D9BFDCD008C9DB10668DAA4C41E01A98D6 701A51429F144D5D9460E50850F55A07F35F721248D215EFDCECCA02E9AC1CF2
ML-DSA-44 DA0AAB120F3CAF12B62D72C4B764FE47502410125FA3137827AA55F8B1B0AFFA E91CC190F7DD8357A5AADDEF6AB717B7B3AC4CCB3F7DA950453CD92A397991FF 5467A7F2B82F6010CFE658AE18B72F347A9ACC7C4FC90303ADF93FFB5F612A63 A82258C53B5934638F26D6A25B5E093D3724012E79A3392FFA398162C4105517
ML-DSA-44 563E184C05A6945E6C72225E197375EC8186460ADF6B970ED837EDB2CC37CE0D 654AB2600BD29986F24AB4AC0BC2F1FF6E32A2EB189AB58D0A33579B92130DC4 24031DAF81B8BDD151FC61F5AD919E82FA18DFD2E1EB4725D82E81879B0020F6 AE5C85BED5861B80EA205D030D0D471D87E72E658A1141608481A116CAF9FA31
ML-DSA-44 4E21C3CDB838083C5DC68AD48DA70A1C3B858B55E14772A608BDD7FE6FC10681 73A5E94A0D7326DFABDCCC0120E7DF22CA7EA8F20E3CE3805915B32A7A8B44F7 D54E634AF8B5F55A5DC4F81755920663C8D33B0B76CBA13CAB15F564A5702EAF 2DFD78BFB7848D7E5DD810CCBB4D1C4A00CE514E63F34CABDF536958CDE6E0D1
ML-DSA-44 E443F1F2006E788785D941A75FB879F682B9A7238389ADA2541EABE2E28EEBD5 3B1A7815B625A5EEB7983A22580D1757A1C880F762D7FE01109FE1B73E3B4F0E C93326B1E76EC026DA5CA229AE4664715B78EB4DB743BC031D54BE08F762817A 0B2C4C827DA81261959A4921729DAE6545326E7B7D3DE9E5615DC36CBB2B24F4
ML-DSA-44 BC0E8F7F3516A9C86D20BFF75AE056905D840414DBC662B41C8FD22C4BD72602 4170198F73493F081E3827135B00C89D389F24DA6F3026684938AE284F38CFF6 79E1889617C550F544E0BFF6746C89FB018F97010E3A72648A36BD844E7FD702 EF9C712D5E96D437D5CA30E4E0A288928977270231E459350FC4730F1B63DA1A
ML-DSA-44 F8299C7C155E6A543C3BB2ED85C5B7DDF41A1CA2C79ABB9146E620A5E3C6CD52 ACC93A8A6CE09E91331765EB3E0B43D514220A6222841753A477508F3316D996 7C352A1621B0B71DB7C988F3C78E13D0DEAF152F337CA3B9D6DDBB7735857FE4 787705010EFFA3F9B2D35CFD7AB9DF0A7162A381618B1F91A7622038B68767F8
ML-DSA-44 613355AC3C5A4721ECA5C35A983351CB48E7DBA30914F04ACB1CD0ECA6B46797 346D0540D9CA2618C7B42AD3D43A236C87625665BA66206DCFCDE94AB607349C 47FB0D336EAC39E02D4C2A1DB74B4196C3490B6EE2F0CA59D9C7C8EAEA53B4DA 324D20D69B4DF8AAD0D38BCAEB900E41D69FF129FF5754044B31E556CC37C38A
ML-DSA-44 B6AA3BA3B3289E2484B7AD76AD17C7B86CEAE632C11B43E4C0826543FFC68054 673D01FED88C527B29A7ADC26F9C73EA352EB4337E5A20670BF331AE7250025E BE77A2BFA9E5F0F03794877AF73DA495D0C3A809EB365A5DE5490C3A4B4FBC90 BEEA3888AF937E011A8D771F451A394255670E303E507F460289B0B019CE470C
ML-DSA-44 C53FB3949EFEB05FABA206F5A6E2B4D214C36454C55FA38F3F571BF1AB83A8AC 3423708B762452EA34E4A175C55DC05EDD7766B49C7832EFB2B51E03BB73DF27 5D1D4555CF47B8F53F8F8C325A2C18F40AA542E81CFBA51D6C26127F4A5F07BF B7B6F02F216AF4B173CFA2468EC1570C0B1C7903CC5E7B15FA78D5FA5263FF04
ML-DSA-44 D9BAC8AC09213F46358B7EF7EB0D9CAFC5492A4A473A01BC6D708E4D8459881A 5AF1DAB893662B90F8DC13AA4C0180610F20F33CDF56EFB4F7F63D26C857AFCC FF05D333B0F908E839DCB8B2D02BBE8864048355EF838CE413701D9B5FFE8B22 5C882CE4205F9214DCB1ACB4B4F8DFE31D3A49B6DD202BFF10B7FCC446CC50AA

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 2: 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 3: 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 Algorithm Registration Properties

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

Table 4: ML-DSA Algorithm Capabilities JSON Values
JSON Value Description JSON Type Valid Values
algorithm The ML-DSA algorithm to be validated string See Section 5
mode The ML-DSA mode to be validated string See Section 5
revision The algorithm testing revision to use string See Section 5
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"
deterministic The ML-DSA signature generation modes supported array of booleans true, false
messageLength The supported message lengths in bits domain Min: 8, Max: 65536, Incr: 8

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.3.2. 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"
        }
    ],
    "parameterSets": ["ML-DSA-44", "ML-DSA-65", "ML-DSA-87"],
    "deterministic": [true, false],
    "messageLength": [{"min": 8, "max": 65536", "increment": 8}]
}

7.3.3. 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"
        }
    ],
    "parameterSets": ["ML-DSA-44", "ML-DSA-65", "ML-DSA-87"]
}

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 5: 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 6: 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 7: 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 8: 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
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 9: 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
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

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": "GDT",
                "parameterSet": "ML-DSA-44",
                "deterministic": true,
                "tests": [
                    {
                        "tcId": 1,
                        "message": "0D873AEFD..."
                    }
                ]
            },
            {
                "tgId": 2,
                "testType": "AFT",
                "parameterSet": "ML-DSA-44",
                "deterministic": true,
                "tests": [
                    {
                        "tcId": 61,
                        "sk": "E94EB...",
                        "message": "00E959E..."
                    }
                ]
            },
            {
                "tgId": 3,
                "testType": "AFT",
                "parameterSet": "ML-DSA-44",
                "deterministic": false,
                "tests": [
                    {
                        "tcId": 71,
                        "sk": "D4E36A5...",
                        "message": "34F4B...",
                        "rnd": "7AFF2F22A..."
                    }
                ]
            }
        ]
    }
]

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 10: 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
pk The public key used to generate the signature hex
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 11: 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
message The message used to verify with the signature hex
signature The signature to verify hex

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",
                "publicKey": "3FE65294...",
                "tests": [
                    {
                        "tcId": 1,
                        "message": "4F0D7...",
                        "signature": "C29A11B6C..."
                    },
                    {
                        "tcId": 2,
                        "message": "84793...",
                        "signature": "6A99215FC2..."
                    }
                ]
            }
        ]
    }
]

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 12: 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 13 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 13: 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 14, Table 15, or Table 16 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 14: 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 15: 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 16: 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)