Zero-Length ctx in ML-DSA CAVP

[Wisiol, Nils]

[AMD Official Use Only - AMD Internal Distribution Only]

Hi,

will CAVP certify ML-DSA verification implementations that exclusively support 0-length context?

Table 7 in draft-celi-acvp-ml-dsa-01 allows the context length to be defined in the registration in the range of 0 to 2040 in increments of 8, but my tests with ACVP-Server defining capabilities that only allow context length zero failed. Failures included:

• min=max=0, increment=8: error: "min must be less than max";
• min=0, max=1, increment=8: error: "increment cannot exceed the difference between min and max";
• min=0, max=1, increment=1: error: "... were not a multiple of 8";
• min=0, max=8, increment=8: produces test vectors with empty and non-empty contexts.

Thanks,

Nils

NILS WISIOL 

MTS Security Center of Excellence  |  AMD
Adaptive and Embedded Computing Group (AECG) 

---------------------------------------------------------------------------------------------------------------------------------- 

Xilinx GmbH, an AMD company

Willy-Brandt-Allee 4, 81829 Munich, Germany

Sitz der Gesellschaft: München, HRB 91773

Geschäftsführer: Brendan Farley, Jens Schmidt

 

[Celi, Christopher T. (Fed)]

Hi,

 

Yes, you need to specify the domain property as a single value rather than as a min, max, increment. That would be “contextLength”: [0] in JSON. See https://pages.nist.gov/ACVP/draft-fussell-acvp-spec.html#name-domain for more examples of different ways to represent domain objects.

 

Thanks,

Chris Celi

[Mike Tate]

Hello all,

I appreciate the discussion and clarity around the handling of contextLength in ML-DSA registrations — I’ve been following with interest and wanted to respectfully offer a few observations that may be helpful from an implementation perspective.

While the use of "contextLength": [0] resolves the immediate issue with ACVP registration, it might be worth considering a more explicit schema pattern — such as a "fixedContext": true flag or a "contextLengthMode": "fixed" construct — to clearly differentiate fixed-length declarations from domain ranges. This could help reduce ambiguity for teams who may expect min = max = 0 to be valid, particularly given how common that pattern is in other domain specifications.

Separately, for implementations targeting constrained or deterministic environments — especially hardware-backed platforms like FPGAs or secure enclaves — support for only zero-length context is often an architectural requirement rather than a configuration choice. In those scenarios, a fixed context simplifies pipeline timing, reduces verification surface, and can be a critical enabler for silicon-based certification. Recognizing this distinction in the registration model could help reduce friction for hardware vendors engaging with ACVP. Just my humble 2 cents.

Lastly, if not already available, a lightweight schema validation or linting tool for ACVP domain definitions could be valuable. Even a minimal pre-submission checker for domain fields like contextLength, keyLen, etc., would help developers catch structural errors early and avoid round-trips with the server.

I realize some of these ideas may already be on the radar or beyond the intended scope of this discussion, but I wanted to offer them in the spirit of shared refinement. I appreciate the excellent work being done here and look forward to learning more from this community.

Warm regards,

Michael Tate

Founder/CTO

StarworX Intellectual LLC

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