Update CROSS to version 2.0

[rtjk]

This pull request updates CROSS from version 1.2 to version 2.0.

CROSS has advanced to the second round of NIST's call for additional signatures, and for the occasion, we have improved a few things. Here are the most relevant changes for liboqs (for a full list, please refer to the changelog submitted to NIST):

-Fixed trivial SUF-CMA forgeries (see #1995) by checking the zero-padding bytes during verification.
-Changed the seed-tree structure, fixing #1958 in the process.
-Resolved the endianness ambiguity in the CSPRNG (see #1961) by explicitly setting the bytes one at a time (we chose this solution over the one in #1983).

The insights we gained from OQS (especially from the liboqs test harness and oqs-demos) were instrumental in some of the improvements in CROSS 2.0. A huge thank you to the OQS maintainers for their great work!

Fixes #1958

Fixes #1995

• Does this PR change the input/output behaviour of a cryptographic algorithm (i.e., does it change known answer test values)? (If so, a version bump will be required from x.y.z to x.(y+1).0.)
• Does this PR change the list of algorithms available -- either adding, removing, or renaming? Does this PR otherwise change an API? (If so, PRs in fully supported downstream projects dependent on these, i.e., oqs-provider will also need to be ready for review and merge by the time this is merged.)

[rtjk]

Regarding the fuzzing tests from #1955, which led to #1958: am I correct in understanding that they are enabled only for Dilithium2 and only in basic.yml, without being included in any other platform test?

[baentsch]

Regarding the fuzzing tests from #1955, which led to #1958: am I correct in understanding that they are enabled only for Dilithium2 and only in basic.yml, without being included in any other platform test?

As far as I understand, "No" and "Yes" in that order: This should ascertain that all OQS SIG algs get fuzzed, but indeed fuzzing only occurs in basic.yml. And whether or not 30secs are enough to perform "enough" fuzzing, I can't comment on. @SWilson4 and @nathaniel-brough most likely have more to say.

[rtjk]

As far as I understand, "No" and "Yes" in that order

Doesn't that test enable only Dilithium2, though?

[baentsch]

As far as I understand, "No" and "Yes" in that order

Doesn't that test enable only Dilithium2, though?

It indeed seems that way -- I guess that's because of the short time allotted for a PR CI. If you do a full build and fuzz test run, all SIG algs should be subject to the test, though. But upon checking the extended weekly test, I indeed don't find extended fuzz testing there as I'd expected. Intentional or oversight @SWilson4 ?

[baentsch]

Thanks for the update @rtjk (and the friendly words!). Integration LGTM.

[bhess]

Thanks for the quick update, @rtjk! Please see the single comment. It appears that the extended tests (full KAT and constant-time tests) haven't run yet. You can trigger them by adding "[extended tests]" to the commit message.

[SWilson4]

As far as I understand, "No" and "Yes" in that order

Doesn't that test enable only Dilithium2, though?

It indeed seems that way -- I guess that's because of the short time allotted for a PR CI. If you do a full build and fuzz test run, all SIG algs should be subject to the test, though. But upon checking the extended weekly test, I indeed don't find extended fuzz testing there as I'd expected. Intentional or oversight @SWilson4 ?

I believe that extensive fuzzing of liboqs happens as part of Google's oss-fuzz project, and that was the motivation for adding the fuzzing tests. We (should) get an email to security@openquantumsafe.org if a fuzzing test fails. The check in our CI is just to ensure we don't break the fuzzing build.

[SWilson4]

@nathaniel-brough Please fact-check the above comment for me!

[nathaniel-brough]

@SWilson4 yeah that's right. There is a small amount of fuzzing done on every pull request to ensure the build doesn't break.

Then every night google/oss-fuzz will build the fuzzers and run them on a distributed cluster for a few hours a day.

Every sig algorithm is enabled during the oss-fuzz build.