The first NIST PQC Standards are published!!

[Moody, Dustin (Fed)]

We are excited to announce that the first three PQC standards have been published!  We want to extend our sincere thanks to all who have participated in the process, and helped us get to this point.  While there is still much work ahead, the publication of FIPS 203, FIPS 204, and FIPS 205 marks a significant milestone in our efforts to provide secure cryptographic standards. 

 

Dustin Moody

(on behalf of the NIST PQC team)

 

 

https://www.federalregister.gov/d/2024-17956

 

 

Announcing Approval of Three Federal Information Processing Standards (FIPS) for Post-Quantum Cryptography

 

The Secretary of Commerce has approved three Federal Information Processing Standards (FIPS) for post-quantum cryptography:

 

• FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard
• FIPS 204, Module-Lattice-Based Digital Signature Standard
• FIPS 205, Stateless Hash-Based Digital Signature Standard

 

These standards specify key establishment and digital signature schemes that are designed to resist future attacks by quantum computers, which threaten the security of current standards. The three algorithms specified in these standards are each derived from different submissions to the NIST Post-Quantum Cryptography Standardization Project. 

  

FIPS 203 specifies a cryptographic scheme called the Module-Lattice-Based Key-Encapsulation Mechanism Standard, which is derived from the CRYSTALS-KYBER submission. A key encapsulation mechanism (KEM) is a particular type of key establishment scheme that can be used to establish a shared secret key between two parties communicating over a public channel. Current NIST-approved key establishment schemes are specified in NIST Special Publication (SP) 800-56A, Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm-Based Cryptography, and SP 800-56B, Recommendation for Pair-Wise Key-Establishment Schemes Using Integer Factorization Cryptography. 

 

FIPS 204 and 205 each specify digital signature schemes, which are used to detect unauthorized modifications to data and to authenticate the identity of the signatory. FIPS 204 specifies the Module-Lattice-Based Digital Signature Standard, which is derived from CRYSTALS-Dilithium submission. FIPS 205 specifies the Stateless Hash-Based Digital Signature Standard, which is derived from the SPHINCS+ submission. Current NIST-approved digital signature schemes are specified in FIPS 186-5, Digital Signature Standard, and SP 800-208, Recommendation for Stateful Hash-Based Signature Schemes. NIST is also developing a FIPS that specifies a digital signature algorithm derived from FALCON as an additional alternative to these standards.

 

Read More!  https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards

NIST FIPS publications: https://csrc.nist.gov/publications/fips 

[Moody, Dustin (Fed)]

Small fix:

The link to FIPS 205 was wrong.  Here's the correct link:

• FIPS 205,  Stateless Hash-Based Digital Signature Standard

Dustin

---

From: 'Moody, Dustin (Fed)' via pqc-forum <pqc-...@list.nist.gov>
Sent: Tuesday, August 13, 2024 9:40 AM
To: pqc-forum <pqc-...@list.nist.gov>
Subject: [pqc-forum] The first NIST PQC Standards are published!!

 

--
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 on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/SA1PR09MB8669741F875140766B082EF3E5862%40SA1PR09MB8669.namprd09.prod.outlook.com.

[Mojtaba B]

Hi Dustin,

Does NIST publish any KATs associated with the final updates on these schemes?

Thanks.

Mojtaba

[Celi, Christopher T. (Fed)]

Hi all,

 

With the publication of the FIPS this morning, these algorithms are now available for algorithm validation certificates through the CAVP. This testing must be performed through an accredited testing lab. The CMVP is also ready for module submissions containing PQC algorithms.

 

Test vectors are available: https://github.com/usnistgov/ACVP-Server/tree/master/gen-val/json-files in the appropriately named folders.

 

Thanks,

Chris Celi

CAVP Program Manager

 

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/SA1PR09MB8669C8F8101747D31BB5C5C4E5862%40SA1PR09MB8669.namprd09.prod.outlook.com.

[Markku-Juhani O. Saarinen]

Hi Chris,

This is great!

However, I may be missing something, but I don't see the IPD->Final changes related to domain separation and pre-hash variants in this CAVP repo yet.

Are these in some other branch or still work-in-progress?

( Readers will note that each FIPS {203,204,205} standard document has a short appendix section at the very end indicating changes from the August 2023 IPD version -- many of these are compatibility-breaking. And there are the entirely new pre-hash primitives too for ML-DSA & SLH-DSA. )

I re-cloned the entire ACVP-Server repo (master branch, as indicated in your message) and checked the C# implementations against these json test vectors. These seem to be the old versions:

- For FIPS 203 / Kyber, the implementation of Algorithm 13 K-PKE.KeyGen() i.e. method K_Pke_KeyGen() seemingly does not implement the new "k" input or 33rd domain separation byte to the G function.

- For FIPS 204, 205 there are no test vectors for the altogether new functions HashML-DSA.Sign(), HashML-DSA.Verify(), hash_slh_sign(), hash_slh_verify(). Furthermore I am not seeing the domain separation changes in the main functions either. 

Best regards,

-markku

Dr. Markku-Juhani O. Saarinen <mj...@iki.fi>

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CO6PR09MB7591C4327373942660753EA2F0862%40CO6PR09MB7591.namprd09.prod.outlook.com.

[Bas Westerbaan]

- For FIPS 203 / Kyber, the implementation of Algorithm 13 K-PKE.KeyGen() i.e. method K_Pke_KeyGen() seemingly does not implement the new "k" input or 33rd domain separation byte to the G function.

I see the same.

 

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CA%2BiU_q%3DN5XQAvXGT8adDw4080OkCAe%3DUX8Zb%2B%3DH0WONhQ_pAkg%40mail.gmail.com.

[Celi, Christopher T. (Fed)]

Hi Markku,

 

Only the internal function is tested by the CAVP. Because of this, we do not test the pre-hash variation. For example, FIPS 204, the first paragraph in Section 5 and the first paragraph in Section 6.

 

Thanks,

Chris

[Markku-Juhani O. Saarinen]

On Tue, Aug 13, 2024 at 5:44 PM Celi, Christopher T. (Fed) <christop...@nist.gov> wrote:

Hi Markku,

 

Only the internal function is tested by the CAVP. Because of this, we do not test the pre-hash variation. For example, FIPS 204, the first paragraph in Section 5 and the first paragraph in Section 6.

Hi Chris (& NIST),

I think it would save a lot of trouble if the actual ML-DSA and SLH-DSA signing and verification functions would be covered in testing too. Testing completely internal functions may be useful for debugging, but it does not give much assurance in relation to interoperability of implementations. For example, signature verification is completely deterministic and does not require randomness, so test vectors could be provided in straightforward way.

Anyway, my reading of Section 6 of FIPS 204 and Section 9 of FIPS 205 was that the standard specifically prohibit making these tested internal functions available in a public API since they are "dangerous" and should never be used by applications. To me it did not suggest that testing must be limited to the internal functions.

"Other than for testing purposes, the interfaces for key generation and signature generation specified in this section should not be made available to applications, as any random values required for key generation and signature generation shall be generated by the cryptographic module. Section {5/10} provides guidance on the interfaces to be made available to applications."

Security assurance given by FIPS 140-3 is also diminished if signature and verification functions are not tested. It is quite easy to use a certified ML-DSA or SLH-DSA module in an insecure way otherwise. For example, I hope that everyone will have the sense to not do stuff like use the SHAKE128 pre-hash option beyond PQC Category 1/2 security level. This limitation is technically stated in both FIPS 204 / ML-DSA and FIPS 205 / SLH-DSA documents, but only indirectly (as far as I can see). See Section 5.4 of ML-DSA and Section 10.2 of SLH-DSA, both of which direct one to look at Table 4 of FIPS 202 which has a sort of an equation min(d,128) for the security of SHAKE128, which then must be correctly interpreted.

"In order to maintain the same level of security strength when the content is hashed at the application level or using HashML-DSA , the digest that is signed needs to be generated using an approved hash function or XOF (e.g., from FIPS 180 [8] or FIPS 202 [7]) that provides at least λ bits of classical security strength against both collision and second preimage attacks [7, Table 4].6 The verification of a signature that is created in this way will require the verify function to generate a digest from the message in the same way to be used as input for the verification function."

Now if HashML-DSA.Verify() was covered in testing, and an attempt to verify an insecure (or less secure) algorithm combo like ML-DSA-65-SHAKE128 would be expected to return "Invalid Signature", this would feel a bit safer.

Best Regards,

- markku

[Stephan Mueller]

Am Dienstag, 13. August 2024, 17:23:49 MESZ schrieb 'Celi, Christopher T.
(Fed)' via pqc-forum:

Hi,

> Hi all,
>
> With the publication of the FIPS this morning, these algorithms are now
> available for algorithm validation certificates through the CAVP. This
> testing must be performed through an accredited testing lab. The CMVP is
> also ready for module submissions containing PQC algorithms.

The first ever set of CAVP certificates for ML-KEM and ML-DSA among others
were awarded [1] to leancrypto [2]. The certificates for those algorithms
include:

- C and streamlined assembler implementations for Intel, ARMv8 and ARMv7

- Linux user space and kernel space, Windows, macOS

[1] https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/
validation-search?
searchMode=implementation&family=1&product=leancrypto&productType=-1&algorithm=1&dateFrom=08%2F13%2F2024&ipp=25

[2] https://leancrypto.org

Ciao
Stephan

[Adam Langley]

On Tuesday, August 13, 2024 at 11:51:01 AM UTC-7 Markku-Juhani O. Saarinen wrote:

I think it would save a lot of trouble if the actual ML-DSA and SLH-DSA signing and verification functions would be covered in testing too. Testing completely internal functions may be useful for debugging, but it does not give much assurance in relation to interoperability of implementations. For example, signature verification is completely deterministic and does not require randomness, so test vectors could be provided in straightforward way.

Not only does testing the "internal" functions force those functions to greater prominence than is wise, they are also not always cut in at a sensible place for exposure (as opposed to exposition). Take the ML-DSA.Sign algorithm: implementations will probably not actually copy the input message in order to prepend the context length and context, instead that will be integrated into the hashing inside the internal function. But now ACVP testing will need a unique mode, otherwise unused, where that is not done.

Also, ACVP doesn't have the boundary correct in at least some cases. Test vectors for ML-DSA keyGen contain a 32-byte seed, and ML-DSA.KeyGen_internal defines that the seed has two bytes prepended to it to specify the ML-DSA configuration. But the ACVP results only work if you don't do that.

Cheers

AGL

[Markku-Juhani O. Saarinen]

Hi Stephan

Wow that was fast! 

But if I'm looking at the right repo, the newly certified leancrypto Kyber code seems to have the same mismatch with the final FIPS 203 specification as the CAVP Server code.

I think this line

https://github.com/smuellerDD/leancrypto/blob/df21fb1ca4d36b961d2b2c3431ff356518b5997e/kem/src/kyber_indcpa.c#L256

should match with Line 1 of Algorithm 13 K-PKE.KeyGen(d), but the G function (i.e. SHA3-512) is computed only of LC_KYBER_SYMBYTES =  32 bytes of "d", without the new "k" domain separator byte.

Fortunately this doesn't divergence from the specification cause tremendous interoperability problems in applications that don't attempt to store private keys as seeds (final part of Section 4 on page 15.)

Yeah, I know that bugs happen but perhaps rushing to obtain certificates before there has been many eyeballs on the "golden reference" is not always wise..

Br,

-markku

--
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 on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/28730219.kyoqqv1GB0%40tauon.atsec.com.

[Celi, Christopher T. (Fed)]

Hi Adam,

 

You are correct on the ML-DSA KeyGen issue. We’ve put in a fix that should go out either later today or tomorrow. Another user on the forum pointed out a similar issue for ML-KEM KeyGen under K-PKE.KeyGen. In both cases, the matrix dimensions were added to the seed, then hashed to form the key material. This is different than the draft FIPS, but covered in Appendix C.2 in FIPS 203, and Appendix D.3 in FIPS 204.

 

Thanks,

Chris

 

From: Adam Langley <a...@google.com>
Date: Tuesday, August 13, 2024 at 3:54 PM
To: pqc-forum <pqc-...@list.nist.gov>
Cc: Markku-Juhani O. Saarinen <mjos....@gmail.com>, pqc-forum <pqc-...@list.nist.gov>, Celi, Christopher T. (Fed) <christop...@nist.gov>
Subject: Re: [pqc-forum] Re: The first NIST PQC Standards are published!!

[Jim Goodman]

Hi Dustin,

  Apologies if I just missed this, but is there any word on the "final" OIDs that are to be used with FIPS 203/204/205 (including the pure and pre-hash variants of FIPS 204/205)?

  Take care.

Jim

--

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 on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/SA1PR09MB8669741F875140766B082EF3E5862%40SA1PR09MB8669.namprd09.prod.outlook.com.

[Phillip Hallam-Baker]

I implemented Dilithium and Kyber according to the final round competition specs. Is there a summary of the changes made (if any)?

I expect I am going to need to run the new test vectors of course. Just wondering if there are other changes I am going to need to make to my code.

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CO6PR09MB7591C4327373942660753EA2F0862%40CO6PR09MB7591.namprd09.prod.outlook.com.

[Stephan Mueller]

Am Dienstag, 13. August 2024, 17:34:01 MESZ schrieb Phillip Hallam-Baker:

Hi Phillip,

> I implemented Dilithium and Kyber according to the final round competition
> specs. Is there a summary of the changes made (if any)?

Apart from the addition of the matrix dimensions, the changes are:

- see https://atsec.com/pqc-kyber-and-dilithium-state-of-the-draft-standards/

- plus the patch: 3a51337651a5810abc74bf25d9e51ce3eac7b125

Ciao
Stephan

[Stephan Mueller]

Am Donnerstag, 15. August 2024, 21:23:05 MESZ schrieb Stephan Mueller:

Hi Stephan,

Sorry, I mean https://github.com/smuellerDD/leancrypto/commit/
3a51337651a5810abc74bf25d9e51ce3eac7b125
>
> Ciao
> Stephan


Ciao
Stephan

[Bas Westerbaan]

For Kyber -> ML-KEM the differences are here in Python:

https://github.com/bwesterb/draft-schwabe-cfrg-kyber/pull/37/files#diff-a000cc308437d8e58cc54b7fb1865d37e9edf7b167463e1558e8a9ecf7255d42

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAMm%2BLwgcTmrkYLym8TiQ%3D9hEvVXDBD66CzVffpPhD3x%2BSimLvg%40mail.gmail.com.

[Phillip Hallam-Baker]

Thanks, i managed to get COVID again and I am still in the brain fog stage, reading the spec was a bit beyond me. I can do planning type stuff Knowing how big the changes are is useful.

Last time it took six weeks to fully recover... ugh.

[BANDI RAVIKUMAR]

I also observed the same. Is there any other link for test vectors for final fips 203 ? 

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAMjbhoVx%2B9aVOp6%3DvbeP3m_uyg1EtwfipNJiEMaT26GL3yTfGw%40mail.gmail.com.

[roderick...@googlemail.com]

I have opened a pull request with new KATs for MLKEM in Kris Kwiatowski’s repository. 

I would welcome independent confirmation of their correctness.

 Rod

On 16 Aug 2024, at 09:33, BANDI RAVIKUMAR <band...@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAJp5hbss8WWVVmvHCnW1rUZQDqt98rHPNTRALzCAexq%2BmzVVLQ%40mail.gmail.com.

[Celi, Christopher T. (Fed)]

Hi,

 

The NIST ACVTS Demo and Prod servers were updated yesterday with the fixes for domain separation on ML-DSA KeyGen and ML-KEM KeyGen. New vector sets can be requested from the API, or are available at https://github.com/usnistgov/ACVP-Server/tree/master/gen-val/json-files.

 

Thanks,

Chris

[Samuel Lee]

Apologies if this is not the correct forum, but I noticed some strange changes in the latest FIPS 140-3 IG with the PQC updates around CASTs.

Implementation Guidance for FIPS 140-3 (nist.gov)

I am particularly concerned with the following section on page 85:

"For key pairs generated for use with approved KEMs in FIPS 203, the PCT (described by the tester in TE10.35.01) shall consist of applying the encapsulation key ek to encapsulate a shared secret K leading to ciphertext c, and then applying decapsulation key dk to retrieve the same shared secret K. The PCT passes if the two shared secret K values are equal." 

FIPS 203 talks about this test as being an appropriate option if the module did not generate the keypair on page 35:
"If the owner of a KEM key pair did not generate the key pair but instead received it from a trusted third party or other source, the owner may optionally perform certain checks on the key pair"

Are the writers of the 140-3 IG aware that forcing a pair-wise consistency test (PCT) of the form described on every ML-KEM key-pair generation will ~double the CPU time spent by parties initiating a key exchange with ephemeral ML-KEM? (i.e. they want perform to keypair generation and decapsulation, but now they have to perform keypair generation, encapsulation and 2x decapsulations)

Was this requirement reviewed by the community before being added to the IG?

I do not see any discussion about PCTs on the PQC forum to date, and I am doubtful that most would see this as a beneficial addition for the 140-3 IG to impose over the standard.

In my view this increase in cost is gives no real gain in security in the presence of CAST for key-generation, and incentivizes ephemeral key reuse at the cost of perfect forward secrecy.

To be fair, I also think the PCT requirements on (EC)DH keypair generation are bad for exactly the same reason.

Additionally, the updated IG text seems to have introduced verbiage suggesting PCTs are requires on any key-pair import. Specifically, the sentence on page 84:

"The PCT shall be performed either when keys are generated/imported, prior to the first exportation, or prior to the first operational use (if not exported before the first use)"

Every other place where pair-wise consistency tests (PCTs) are referred to in the IG say that they are only required on key-pair generation:

"If a cryptographic module generates public or private key pairs, a pair-wise consistency test shall be performed ..."

"Though not a CAST, a pairwise consistency test (PCT) shall be conducted for every generated public and private key pair for the applicable approved algorithm ..."

Was this new implication intentional?

There is also ambiguity when storing a decapsulation key as a seed whether the intent is that importing the seed is an "import" or a "generate" with respect to these requirements.

Best,

Sam

[Markku-Juhani O. Saarinen]

Hi Samuel & All,

Yes this is definitely worthy of further discussion. There were many changes to input validation in FIPS 203 in relation to IPD, and the old Section 6 in the IPD was split into new Sections 6 and 7. These changes are easily ignored because they are not technically "functional." For example, the two-line Algorithm 21 ( ML-KEM.Decaps ) literally does nothing except call Algorithm 18 ( ML-KEM.Decaps_internal ) and return its value. The only difference is in the surrounding text, which discusses input validation.

However, my reading is that one doesn't have to do the checks every time, so it doesn't necessarily affect performance (Section 7.3 in FIPS 203): "However, checking of the decapsulation key need not be performed by the decapsulating party, nor with every execution of ML-KEM.Decaps. Instead, assurance that this check has been performed can be acquired through other means (see SP 800-227 [1])."

The referenced document SP 800-227 [1] does not exist (yet -- it is marked as "forthcoming" in re the references), so perhaps there is still an opportunity to still influence these aspects. And as we know, the IG document can be revised "dynamically" at any time. Samuel is right that the common use case of ephemeral key exchange needs to be explicitly discussed so that certification labs will know how to deal with it.

Ps. I can report that after the "hotfix" ( https://github.com/usnistgov/ACVP-Server/commit/65370b861b96efd30dfe0daae607bde26a78a5c8 ) I am able to match the CAVP test vectors with the specification for FIPS 203 / ML-KEM. Bas Westerbaan made a similar positive comment about the situation, but he can mention if there are caveats.

I'm still working on FIPS 204 / ML-DSA, but it is better now (ML-DSA test vectors were also modified by the fix). However the FIPS 204 specification, in turn, has errors ( https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/iwUz64oTOSo/m/nC_2W8lYBgAJ ) and the anyway test vectors don't yet cover the ML-DSA signing and verification functions yet (just the internal functions that "must not be used in applications" !). So, there is still some work to be done here before there is confidence to start "shipping products." Hopefully, this will now be accelerated as documents are out and public vetting of the testing system is ongoing.

Best Regards,

-markku

Dr. Markku-Juhani O. Saarinen <mj...@iki.fi>

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/ac77dafc-0665-4a00-be5f-f6baac80618dn%40list.nist.gov.

[Stephan Müller]

Am Samstag, 17. August 2024, 14:05:57 MESZ schrieb Markku-Juhani O. Saarinen:

Hi Markku-Juhani,

> Hi Samuel & All,
>
> Yes this is definitely worthy of further discussion. There were many
> changes to input validation in FIPS 203 in relation to IPD, and the old
> Section 6 in the IPD was split into new Sections 6 and 7. These changes are
> easily ignored because they are not technically "functional." For example,
> the two-line Algorithm 21 ( ML-KEM.Decaps ) literally does nothing except
> call Algorithm 18 ( ML-KEM.Decaps_internal ) and return its value. The only
> difference is in the surrounding text, which discusses input validation.
>
>
> However, my reading is that one doesn't have to do the checks every time,
> so it doesn't necessarily affect performance (Section 7.3 in FIPS

> 203): *"However,

> checking of the decapsulation key need not be performed by the
> decapsulating party, nor with every execution of ML-KEM.Decaps. Instead,
> assurance that this check has been performed can be acquired through other

> means (see SP 800-227 [1])."*

May I propose to move the discussion around FIPS 140 compliance and FIPS 140
IGs to the CMUF, where participants from NIST, the FIPS validation labs,
implementors and end users discuss? Most of them have no idea about the PQC-
Forum and thus would miss this discussion. Specifically, those questions are
seemingly unrelated to the mathematical / cryptographic discussions that
usually occur on this mailing list and thus perhaps not interesting to others
here?

The CMUF is accessible at [1].

[1] https://www.cmuf.org/

Ciao
Stephan

[Peter Schwabe]

Stephan Müller <smue...@chronox.de> wrote:
> Am Samstag, 17. August 2024, 14:05:57 MESZ schrieb Markku-Juhani O. Saarinen:
>
> Hi Markku-Juhani,

Hi Stephan,

I would be very happy if this discussion also continues here. I'm not
aware of CMUF and I'm probably also not interested in most of the
discussions there -- but I'm very interested in the discussions around
input validation for ML-KEM and probably several other people here are
as well.

All the best,

Peter

[Celi, Christopher T. (Fed)]

I helped write some of the IG for self-tests mentioned here.

 

Pairwise consistency tests PCTs are a requirement from the ISO document that FIPS 140-3 references, especially surrounding asymmetric cryptography. It is not something introduced by this IG. The IG provides concrete steps to perform the PCTs for each individual algorithm.

 

Yes, we know it is very inconvenient and costly regarding time. There is no way around it, as it is the requirement from ISO. The requirement was brought up to the PQC Consortium hosted by the NCCoE, and also brought to the Crypto Module User Forum (CMUF), an open community of testing labs and interested vendors.

 

Regarding your questions on key import, I’ll pass that along to the Cryptographic Module Validation Program along with this thread.

 

Thanks,

Chris Celi

 

From: 'Samuel Lee' via pqc-forum <pqc-...@list.nist.gov>
Date: Friday, August 16, 2024 at 7:27 

PM

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/ac77dafc-0665-4a00-be5f-f6baac80618dn%40list.nist.gov.

[Bobby McGee]

Where should we send not-so-important typographical comments that might be incorporated into a future revision, if NIST even wants them?  For instance, flipping through the docs one might notice things like:

- In FIPS 205, some instances of "should" are in typewriter font while others are bold.

- In FIPS 204, Appendix A, both "Montgomery_Reduce" and "MontgomeryReduce" are used.

- FIPS 204 is in a different font than the other two.

[Moody, Dustin (Fed)]

You can send such comments to pqc-co...@nist.gov.

We will collect them, and in a future update they can be addressed.

Thanks,

Dustin

---

From: pqc-...@list.nist.gov <pqc-...@list.nist.gov> on behalf of Bobby McGee <janewayki...@gmail.com>
Sent: Monday, August 19, 2024 11:51 AM
To: pqc-forum <pqc-...@list.nist.gov>
Cc: Celi, Christopher T. (Fed) <christop...@nist.gov>; Samuel Lee <samue...@microsoft.com>

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/99c8da86-2758-4f52-bbc2-61e7bdaf6147n%40list.nist.gov.

[Samuel Lee]

Thanks for the feedback around the CMUF - I was not aware of that forum; I have joined it and will take a look in the next few days.

Just to push back on the "no way around it" statement w.r.t. the introduction of the PCT language in FIPS 140-3 IG.

I believe there is nothing stopping a less costly pair-wise consistency test to be defined for ML-KEM in the case of a PCT immediately after keypair generation?

The exact form of an appropriate PCT is up to debate, but, for example, computing implicit rejection in the decapsulation operation is a complete waste of time in this case (if you fail K-PKE.Decrypt you can then immediately fail keygen, rather than implicitly reject and then compare and fail).

One could envision much more extreme cheap checks for pair-wise consistency (i.e. just check that the encaps key (ek) encoded in the decaps key (dk) is the same as encaps key you just generated ek).

I think there are a spectrum of flavors of PCT that could satisfy ISO, we should make sure that CMVP does not impose something that is needlessly onerous.

Best,

Sam

[Watson Ladd]

If pairwise consistency checks are applied to every key generation
including for ephemeral agreements there is a massive performance hit.
At Akamai we had to patch this behavior out of OpenSSL 3.0 when used
with ephemeral DH for TLS termination.

> To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/8a5d2d5a-e804-4e3c-aee1-b30402fc4878n%40list.nist.gov.



--
Astra mortemque praestare gradatim

[Michael Scott]

If you mean these test vectors

https://raw.githubusercontent.com/post-quantum-cryptography/KAT/42df1f79b9c981d029f70684fb7a7ecea15bc777/MLKEM/kat_MLKEM_768.rsp

Then I checked out a few of them against my independent implementation, and they worked just fine.

Mike Scott

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/A4A457FC-714B-469B-9C4A-2891174A76A6%40googlemail.com.

[Kris Kwiatkowski]

Thanks Roderic,

I'm sorry for late replay.
I've also checked those vectors against ours (PQShield) implementations. All vectors seems OK.

Kind regards,
Kris

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAEseHRo%2B04k4VJCZGWe2a%3DuQSOeEy2qjOUnbbWnZbOC6Vpz7kA%40mail.gmail.com.

[Anjan Roy]

Dear all,

Good day !

Just generated some ML-KEM-{512,768,1024} test vectors (of more expanded form, see 👇) from HEAD (commit 10b478fc3cc4ff6215eb0b6a11bd758bf0929cbd) of `main` branch of https://github.com/pq-crystals/kyber.git.

This form of test vectors is easier for me to use in my implementation of ML-KEM @ https://github.com/itzmeanjan/ml-kem. Though note that, my implementation is not yet conformant to the standard, rather it is to the "draft" standard.

Generated KAT files and reproducible steps are described in https://gist.github.com/itzmeanjan/c8f5bc9640d0f0bdd2437dfe364d7710.

Cheers,

Anjan Roy

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/dc3723d7-ba7a-4ffd-a26d-128da3c8b3fc%40amongbytes.com.

[Eswari Devi N]

Hi all,

Good day!

Regarding the validation of ML-KEM implementation, is NULL input condition checking a mandatory test case?, if so, what additional information will be required to perform NULL input condition check. 

Also, will there be any additional specific tests to be carried out?

Thanks

Eswari Devi 

[Celi, Christopher T. (Fed)]

Hi Eswari,

 

There are currently no tests for the validation of ML-KEM around null input checks. In general, null input checks fall within a gray area of crypto module testing. Is it the responsibility of the crypto algorithm implementation to check inputs, or the responsibility of the crypto module providing the inputs to check those inputs? At the moment, we would expect the FIPS testing lab to cover those requirements when submitting the crypto module to the CMVP. Is this the ideal solution? Certainly not. The way the standard is written leads to this testing being useful within the validation program. It may be something we add soon.

 

Thanks,

Chris Celi

CAVP Program Manager

 

From: Eswari Devi N <ndevi...@gmail.com>
Date: Thursday, January 9, 2025 at 12:51 

AM