Tracker for FIPS204 / ML-DSA

[bhess]

Tracks liboqs ML-DSA #1919

This PR Integrates ML-DSA and (non-composite) hybrids.
However, it does not yet include support for the updated composite signatures with ML-DSA.

@feventura: It would be great if you could amend this PR to incorporate the updated composite signature support. Alternatively, you could submit a follow-up PR for those changes.

[dstebila]

Can we revive this PR to get ML-DSA landed in oqs-provider? @bhess is there anything more you were planning before converting this from a draft PR?

[dstebila]

@feventura @johngray-dev do you have any feedback whether this is heaving as expected in interop with other ML-DSA implementations?

[bhess]

Tests are passing after the merge of open-quantum-safe/liboqs#1919, so the PR is now ready.

[feventura]

@feventura: It would be great if you could amend this PR to incorporate the updated composite signature support. Alternatively, you could submit a follow-up PR for those changes.

@bhess I look at the changes and I think it does not require any change for the composite. The composite OIDs used in there expect to use ML-DSA not dilithium.
The composite interop will still fail, but that's because I didn't implemented the -03 changes yet.

@feventura @johngray-dev do you have any feedback whether this is heaving as expected in interop with other ML-DSA implementations?

@dstebila I don't think there is interop with this PR and other implementations, but as soon as this is merged and the openquantumsafe/oqs-ossl3 is updated we will see the results of the interop in the Automated Interop Table.
Right now, oqs is failing on the ML-DSA interop, I expect that this PR will fix it.

[baentsch]

Please also update the code points as per #578

[bhess]

Thank you, @baentsch and @tomato42, for pointing out the ML-DSA code points. I’ve updated the PR accordingly.

[SWilson4]

@dstebila I don't think there is interop with this PR and other implementations, but as soon as this is merged and the openquantumsafe/oqs-ossl3 is updated we will see the results of the interop in the Automated Interop Table. Right now, oqs is failing on the ML-DSA interop, I expect that this PR will fix it.

It would be nice to see the results of these interop tests this before we release liboqs 0.12.0. @feventura If I'm understanding correctly what you wrote here, the tests will run automatically when a new version of oqs-ossl3:latest is pushed to Docker Hub. If that is indeed the case, what about (manually?) building and pushing a new image based on liboqs 0.12.0-rc1 and this branch of oqs-provider as part of the pre-release testing process? Tagging @baentsch and @ajbozarth as the people who likely know most about the feasibility of doing this.

[baentsch]

what about (manually?) building and pushing a new image based on liboqs 0.12.0-rc1 and this branch of oqs-provider as part of the pre-release testing process?

Good idea and easily doable. But a bit "unfriendly" towards "unsuspecting" users of that image. @feventura : Is there any chance one can tweak the tag pulled for that automatic test? When I made these images available a few years (really?) back, I always tagged them ":ietfxyz" to ensure the right image is used at the IETF xyz hackathon event. Would you know who could change that from ":latest" to maybe also run the automated test on a tag like ":prerelease"? Or even simpler: What'd be needed for us (s part of the release process) to create such a test matrix?

[feventura]

If I'm understanding correctly what you wrote here, the tests will run automatically when a new version of oqs-ossl3:latest is pushed to Docker Hub.

Not quite @SWilson4, correcting myself, the actions will not run automatically when a new version of oqs-ossl3 is published, instead it will run when a push is done to any branch, but I or any with admin access (including you @baentsch ) could go there and trigger a new run on the git actions after the image is updated.

Now for the interop with this PR I see three options:

1. I or @baentsch can create a branch on the hackathon repository and make change the tag for the docker image. That page would not be uploaded to the hackathon github (because the action only upload when is run from main) but the .html that would be uploaded can be downloaded.
2. Run this tests locally, and since this is already on gitaction someone could clone the hackathon repository and run the actions using act after making the changes on the tag for the docker image.
3. Run the test manually, here is how you do it https://github.com/IETF-Hackathon/pqc-certificates/blob/master/docs/compat_matrix_instructions.md, the only change is that we are using R4 format, not R3.

[baentsch]

any with admin access (including you @baentsch )

Yikes. I still have these rights?!? I'll surely not use them without knowing exactly what I'd need to do -- I simply didn't follow the development on the hackathon github (but assumed @praveksharma does).

Now for the interop with this PR I see three options:

Thanks for that explanation . Option 1 is imo too "heavy handed"; option 3 sounds like the fastest short-term approach and option 2 like the best "CI-able" long-term approach.

Considering @praveksharma both volunteered doing the release and also participates in the hackathon (right?) may I suggest him taking on implementing option 3 in the release test script, followed by 2 in CI (or just 2 if quick-and-easy) to enhance the quality of the release testing in the long run?

[johngray-dev]

I created some artifacts using liboqs and ML-DSA and manual testing shows they interop with the other providers in our hackathon project. However, the docker image openquantumsafe/oqs-ossl3 that is used is still failing to verify all artifacts. Is this docker image picking up the latest 012.0 (or even the 0.12r1) version of liboqs? I suspect it must not, otherwise the automated table from the hackathon would be showing oqs passing with positive results (instead of failing).

[baentsch]

The liboqs code base or version does not describe the functionality in an oqsprovider until both are released and documented to work together. Only an oqsprovider 0.8.0 (or as of yesterday, main) will work with liboqs 0.12.0: We had been waiting for the interop confirmation before landing the final (O)IDs. Now the docker image can follow (manually or automatically built as per preference, e.g., of @praveksharma ).

[johngray-dev]

@feventura: It would be great if you could amend this PR to incorporate the updated composite signature support. Alternatively, you could submit a follow-up PR for those changes.

@bhess I look at the changes and I think it does not require any change for the composite. The composite OIDs used in there expect to use ML-DSA not dilithium. The composite interop will still fail, but that's because I didn't implemented the -03 changes yet.

@feventura @johngray-dev do you have any feedback whether this is heaving as expected in interop with other ML-DSA implementations?

@dstebila I don't think there is interop with this PR and other implementations, but as soon as this is merged and the openquantumsafe/oqs-ossl3 is updated we will see the results of the interop in the Automated Interop Table. Right now, oqs is failing on the ML-DSA interop, I expect that this PR will fix it.

As mentioned above, I manually used libOQS 0.12 to interop with the other implementations in the IETF hackathon, and it works. We are still waiting for the dockerhub image to be updated to 0.12. Once that is done the automated interop table look much better!