Update Kyber and Dilithium to FIPS versions

[dstebila]

Once the FIPS drafts are released, we'll need to update Kyber and Dilithium based on the tweaks added by NIST.

Upstream already has started on this:

• https://github.com/pq-crystals/kyber/tree/standard
• https://github.com/pq-crystals/dilithium/tree/standard

[beldmit]

Could you please provide the links to the FIPS drafts?

[dstebila]

They're not publicly available yet.

[bhess]

The FIPS drafts are now available:
FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard
FIPS 204, Module-Lattice-Based Digital Signature Standard
I'll do a pull from the pq-crystals repo/standard branch next week.

[dghgit]

One quick question (I hope) about this. I've heard the OIDs for Dilithium may be updated to reflect the change in algorithm. If so would it be possible to find out what the OID values will be now? I'm in the process of updating myself but want to make sure I can still interop (have some users chaffing at the bit as well). Thanks.

[baentsch]

the OIDs for Dilithium may be updated to reflect the change in algorithm.

The OIDs must be updated if KATs change. If IBM (current dilithium name range holder) or NIST (standards range) doesn't do it, I will :-) But as I am member of neither organization I cannot predict what those values will be. If OQS were the only organization interested in ensuring separation of "old" vs "new" artifacts, the numbers will be progressing from here which is our master file for OID allocation of algorithms without other OID management.

[dghgit]

Thanks for the definitive answer and the link. Okay, I guess we're waiting on IBM then. I hope they're feeling lively!

[bhess]

One quick question (I hope) about this. I've heard the OIDs for Dilithium may be updated to reflect the change in algorithm. If so would it be possible to find out what the OID values will be now? I'm in the process of updating myself but want to make sure I can still interop (have some users chaffing at the bit as well). Thanks.

Yes, an update is needed because of the KAT change.
Planning to use the following OIDs for the FIPS drafts of Dilithium/ML-DSA:

Dilithium2 (ML-DSA-44): 1.3.6.1.4.1.2.267.12.4.4
Dilithium3 (ML-DSA-65): 1.3.6.1.4.1.2.267.12.6.5
Dilithium5 (ML-DSA-87): 1.3.6.1.4.1.2.267.12.8.7

[dghgit]

thanks, that's a big help. I'll get to work.

[baentsch]

thanks, that's a big help. I'll get to work.

Sad I cannot say the same: I've got to wait for "liboqs" to merge this and only then can add it to "oqsprovider" -- and only after that can do a new iteration after IETF-Hackathon/pqc-certificates#65 gets merged (if it gets merged -- still waiting for feedback there whether/when to do it).

[bwesterb]

@cjpatton Did we pin liboqs? Otherwise things will break when this lands.

[cjpatton]

It's pinned via Cargo.lock; it'll break if we do cargo update.

[cjpatton]

@thomwiggers are you guaranteeing semantic versioning for the oqs crate? I.e., will any wire-breaking changes to the implementations of Kyber appear in the next major version (0.9)?

[baentsch]

@cjpatton FWIW, this issue isn't closed, the implementing PR didn't merge, so no interop breaking changes to Kyber occur in v0.9.0.

[thomwiggers]

@cjpatton yes, that is the intention. We are currently following the same version numbers as liboqs, but we're likely going to have to start doing our own versioning---but the intention is to stick to semver.

[baentsch]

we're likely going to have to start doing our own versioning

This is very sensible -- we also do this with oqsprovider: FWIW, in the provider we add reference to the liboqs version used in addition: For us it is helpful to pinpoint code version "surprises" filtering through the library layers (and/or liboqs code coming pre-installed).

[mkannwischer]

I've put the updated aarch64 implementations (along with ref and avx2) into PQClean. These are based on the standard branch of the Kyber and Dilithium repo.

• Kyber: Update to NIST Draft Standard PQClean/PQClean#504
• Dilithium: Update to NIST Draft Standard  PQClean/PQClean#511

[baentsch]

This is to put in writing what was proposed verbally yesterday: Consider changing this issue to read "Integrate Kyber and Dilithium FIPS versions" using a different algorithm name: That way we could keep supporting Kyber(R3) deployments and enable tests with the standards candidate code -- without having (everybody) to wait for the discussion between NIST and the Kyber team to conclude.

[dstebila]

This is to put in writing what was proposed verbally yesterday: Consider changing this issue to read "Integrate Kyber and Dilithium FIPS versions" using a different algorithm name: That way we could keep supporting Kyber(R3) deployments and enable tests with the standards candidate code -- without having (everybody) to wait for the discussion between NIST and the Kyber team to conclude.

I think it's still more complicated. If I understand correctly (and I might be wrong here) there's actually 3 technically incompatible versions at the moment:

• the Round 3 versions, which are what we currently have on main and are what Cloudflare etc. is running
• NIST FIPS drafts, which includes intentional tweaks to the round 3 versions, as well as what the PQ-Crystals team might describe as unintentional changes
• the PQ-Crystals team's updated implementation, which includes the intentional tweaks to the round 3 versions but not the so-called unintentional changes

[bwesterb]

... and there might be a fourth: the final versions might still differ from the drafts that are out now, and the PQ-Crystals's implementation.

This explosion of versions is why we wait for the final version before updating.

[baentsch]

explosion of versions

Yikes. So what is it that @mkannwischer now added to PQClean? What is it that PPCoE tests (@christianpaquin )? IETF (@praveksharma )? @crockeea does your team also "stays put" as per

wait for the final version before updating.
?

[crockeea]

After the LibOQS meeting yesterday, we discussed this. We are not planning so any updates until the FIPS drafts are finalized. We’re sticking with Round 3 until then.

[christianpaquin]

What is it that PPCoE tests (@christianpaquin )?

The NCCoE? We test interoperability between implementations provided by consortium members.

[baentsch]

What is it that PPCoE tests (@christianpaquin )?

The NCCoE? We test interoperability between implementations provided by consortium members.

blush :-/ At least 60% of letters matching. My question was whether you intend/do test Kyber/Dilithium FIPS versions now or also wait until their are truly final, i.e, whether we should postpone this issue until middle 2024 or add the algs now, e.g., under different names.

[bhess]

NIST now published some test vectors for the ML-KEM and ML-DSA drafts:
https://csrc.nist.gov/Projects/post-quantum-cryptography/post-quantum-cryptography-standardization/example-files

I've tested them against the pq-crystals Kyber and Dilithium "standard" branches, and they seem to match (although it's only one test per algorithm).

The tests are "intermediate values" and can't be used exactly the same way as the KAT, but I'll look at adding them to the liboqs "standard" branch.

[dstebila]

NIST now published some test vectors for the ML-KEM and ML-DSA drafts: https://csrc.nist.gov/Projects/post-quantum-cryptography/post-quantum-cryptography-standardization/example-files

I've tested them against the pq-crystals Kyber and Dilithium "standard" branches, and they seem to match (although it's only one test per algorithm).

The tests are "intermediate values" and can't be used exactly the same way as the KAT, but I'll look at adding them to the liboqs "standard" branch.

Thanks for looking into this Basil. So what do we make of the alleged different between the NIST FIPS drafts and the PQCrystals implementation? Did I misunderstand and perhaps they're not functionally different? Or did NIST generate the test vectors using the PQCrystals implementation?

[baentsch]

Comment from the side line: According to this, BouncyCastle, cryptonext and WolfSSL have support for ML-KEM integrated. It may be worth while running interop (@praveksharma at the next Hackathon?) against those implementations to see how different people interpret the specs: At least BC is guaranteed to not use the reference code.

[bhess]

So what do we make of the alleged different between the NIST FIPS drafts and the PQCrystals implementation? Did I misunderstand and perhaps they're not functionally different? Or did NIST generate the test vectors using the PQCrystals implementation?

The "Note on the intermediate values" sections on the NIST page contain some clarifications/corrections to the FIPS drafts. Looking at the test vectors published, this appears to sync it with the pqcrystals implementation. However, I don't think that the implementation that generated the test vectors is available.

It may be worth while running interop (@praveksharma at the next Hackathon?)

I agree.

[vkosuri]

Hi, are there any plans on this draft PR #1537 to release in 0.9.3? If not, are there any tentative timelines if not mid of 2024?

[bhess]

Hi, are there any plans on this draft PR #1537 to release in 0.9.3? If not, are there any tentative timelines if not mid of 2024?

There are still a few open points in #1626 that I plan to finalize soon. This won't be part of a 0.9.3 release but rather a 0.10 release because of new algorithms added.