search

open-quantum-safe / liboqs

C library for prototyping and experimenting with quantum-resistant cryptography
https://openquantumsafe.org/
Other
1.83k stars 447 forks source link

Update Kyber and Dilithium to FIPS versions #1521

Closed dstebila closed 7 months ago

dstebila commented 1 year ago

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:

beldmit commented 1 year ago

Could you please provide the links to the FIPS drafts?

dstebila commented 1 year ago

They're not publicly available yet.

bhess commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

bhess commented 1 year ago

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 commented 1 year ago

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

baentsch commented 1 year ago

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 https://github.com/IETF-Hackathon/pqc-certificates/pull/65 gets merged (if it gets merged -- still waiting for feedback there whether/when to do it).

bwesterb commented 12 months ago

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

cjpatton commented 12 months ago

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

cjpatton commented 12 months ago

@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 commented 12 months ago

@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 commented 12 months ago

@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 commented 12 months ago

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 commented 12 months ago

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.

baentsch commented 11 months ago

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 commented 11 months ago

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:

bwesterb commented 11 months ago

... 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 commented 11 months ago

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 commented 11 months ago

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 commented 11 months ago

What is it that PPCoE tests (@christianpaquin )?

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

baentsch commented 11 months ago

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 commented 11 months ago

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 commented 11 months ago

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 commented 11 months ago

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 commented 11 months ago

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 commented 8 months ago

Hi, are there any plans on this draft PR https://github.com/open-quantum-safe/liboqs/pull/1537 to release in 0.9.3? If not, are there any tentative timelines if not mid of 2024?

bhess commented 8 months ago

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 https://github.com/open-quantum-safe/liboqs/pull/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.