Update Falcon implementation

[thomwiggers]

Updates Falcon to the latest version of the code.

• See also Update Falcon to 20230207  #1386 (version number is now better specified, instead of just the day I got the code from Thomas Pornin).

Closes #1390 and #1315

• 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 the list of algorithms available -- either adding, removing, or renaming? Does this PR otherwise change an API? (If so, PRs in oqs-provider, OQS-OpenSSL, OQS-BoringSSL, and OQS-OpenSSH will also need to be ready for review and merge by the time this is merged.)

[baentsch]

FWIW, the "randomness" error is gone/repeated speed tests pass -- Thanks, @thomwiggers! However, the constant_time tests fail on my machine.

[baentsch]

• Clarity to be obtained as to how this code relates to the NIST competition
• license update
• version ID update
• constant time checks should pass (or algorithm should be documented not having this property/excluding it from testing, see document BIKE lacks constant time protection #1397 as example for the latter)

[thomwiggers]

The implementation should be constant-time; and there aren't too many differences with the implementation that was here before. The main difference seems the checks to resolve #1315. Maybe the existing suppressions need to be reconstructed because a bunch of the code moved back from c files into .h files

[baentsch]

the existing suppressions need to be reconstructed because a bunch of the code moved back from c files into .h files

Will you add this to this PR then or do you want to do a separate PR as soon as weekly CI constant time testing fails (maybe also a "solution" for #1400)?

[thomwiggers]

I have no idea how to do that

[baentsch]

I have no idea how to do that

This is documented in https://github.com/open-quantum-safe/liboqs/blob/main/tests/test_constant_time.py .

[thomwiggers]

I'm not sure if I will have time in the coming month to write these valgrind suppression files, I'm afraid, so I would appreciate it if someone could take over this PR.

[dstebila]

I'm not sure if I will have time in the coming month to write these valgrind suppression files, I'm afraid, so I would appreciate it if someone could take over this PR.

I've updated the constant-time suppression files.

[dstebila]

• Clarity to be obtained as to how this code relates to the NIST competition
• license update
• version ID update
• constant time checks should pass (or algorithm should be documented not having this property/excluding it from testing, see document BIKE lacks constant time protection #1397 as example for the latter)

@baentsch What do you mean by "license update"?

As for the version ID and how it relates to the NIST competition, @thomwiggers I can email Thomas Pornin if you like to ask what version identifier he would give this, unless you already have an answer to that question.

[baentsch]

@baentsch What do you mean by "license update"?

This has been adressed in the mean time by 1d93158

[baentsch]

I've updated the constant-time suppression files.

Thanks very much. They're looking good to me (and the tests pass on my machine). That indeed only leaves the version ID question open to close this.

[dstebila]

I've updated the constant-time suppression files.

Thanks very much. They're looking good to me (and the tests pass on my machine). That indeed only leaves the version ID question open to close this.

Version ID question is now resolved: an email from Thomas Pornin to me and Thom says that he would call this version "20211101", so I've labelled it as such.

[dstebila]

Any objections to merging?

[baentsch]

Any objections to merging?

Nope. Thanks @thomwiggers for the PR and @dstebila for addressing all issues (I had :)