NIST standards published

[planetf1]

The final standards have been published for

• FIPS-203 - Module-Lattice-Based Key-Encapsulation Mechanism - https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf
• FIPS-204 - Module-Lattice-Based Digital Signature - https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf
• FIPS-205 - Stateless Hash-Based Digital Signature - https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.205.pdf

Now I expect we'll see more and more traction!

[baentsch]

What do you mean by "traction" @planetf1 ? What concrete implications do you see for OQS -- beyond #1891 (thanks to @bhess for creating that concrete issue!)? I for example expect many more implementations to become available--should we for example actively support interop testing beyond what's already there or leave that "to the market"?

[planetf1]

By 'traction' I just mean I expect there to be more interest & actual action in the industry at large.

In addition to the concrete actions of adopting ML-KEM, The implication for OQS is for us to address the production/research discussion - and IMO move more to providing information for people to make their own minds up about whether to use oqs.

[baentsch]

expect there to be more interest & actual action in the industry at large.

Agreed. Would also be nice if we could find ways to direct some of that "industry action" towards GH contributions.

address the production/research discussion - and IMO move more to providing information for people to make their own minds up about whether to use oqs

Makes sense. Normally the job of a "product owner/manager": Position the product, provide arguments as to why it should be used (and when/where) and making sure the product's promises are worked towards & met. Getting on board such PM via LF was AFAIK the prime reason the OQS team agreed to join LF/PQCA because no-one in the original team volunteered to do this and everyone already then (a year ago) agreed this is needed (and probably needs to be paid for).