Add MQOM

[rben-dev]

This PR adds the MQOM signature scheme. MQOM is part of on-ramp Round 2 NIST candidates, In order to avoid too many variants that would overload the library, we only provide implementations for GF(16) MQOM fast and short (with 3 or 5 rounds), as this is the best choice for a speed and signature size balance.

Three implementation profiles are integrated to liboqs:

• AVX2: this makes use of AVX2 and AES-NI extensions, suited for modern amd64 platforms.
• default: this is a portable implementation suitable for most desktop-like platforms (e.g. arm64 Mac M1, etc.)
• memopt: this is a portable implementation with memory optimizations that are more suitable for platforms with stringent memory constraints (e.g. embedded platforms or targets with small stacks, etc.)

Here are some notable elements for this MQOM integration:

• MQOM uses Keccak, and we use the liboqs API for this.
• MQOM in security level 1 uses AES-128, and we use liboqs API for this. However, for security levels 3 and 5 Rijndael-256-256 is used, and hence we had to provide local implementations for this (see in the rijndael/ folder upstream).
• MQOM uses a large stack in the AVX2 and default implementations:
  • We had to deactivate the threaded signature tests in tests/test_sig.c. This is particularly useful for Mac OS platforms where the threads stacks is quite small.
  • We also had to adapt the tests/test_leaks.py file by providing --max-stackframe=20480000 to valgrind as discussed in issue Maximum stack usage for valgrind "leak test" #2360 : without this the CI tests fail with false positives. The strategy for this fix can be of course discussed. The fix is part of the PR.

Many elements of this PR have been produces with the copy_from_upstream.py automation (thanks for this): I only had to format with astyle the produced files in src/sig/mqom/ root.

Thanks in advance for considering the inclusion of MQOM in the library, as we believe this can be useful for exploring on-ramp candidates. Please do not hesitate if anything is wrong or missing!

• 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. Also, make sure to update the list of algorithms in the continuous benchmarking files: .github/workflows/kem-bench.yml and sig-bench.yml)

[baentsch]

Hi @rben-dev -- thanks very much for bringing up this PR. For starters, could you please fix up the DCO error message as per CI help messages? I also triggered the other CI jobs to see how things look like before taking a deeper look into your contribution.

[rben-dev]

Hi @baentsch,

Thank you very much for your prompt reply and help. The DCO issue should be resolved.

However, from the CI failures:

• For the CBOM check, what is expected?
• For the Verify copy_from_upstream state after copy, the issue seems to be in the usage of supported-platforms: all in my META files for the portable implementations (default and memopt). I switched to this because the expected supported_platforms key triggers an error (at least on my Linux distro) when applied locally:

  File "liboqs/scripts/copy_from_upstream/copy_from_upstream.py", line 911, in <module>
    copy_from_upstream(slh_dsa_instruction)
    ~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^
  File "liboqs/scripts/copy_from_upstream/copy_from_upstream.py", line 759, in copy_from_upstream
    process_families(instructions, os.environ['LIBOQS_DIR'], True, True)
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "liboqs/scripts/copy_from_upstream/copy_from_upstream.py", line 661, in process_families
    if req['architecture'] == 'arm_8':
       ~~~^^^^^^^^^^^^^^^^
TypeError: string indices must be integers, not 'str'

The local CI on my fork was happy with the original commits, although not performing these basic checks for some unkown reason ... I am really sorry if I have missed something obvious here.

Thanks in advance,

[rben-dev]

For completeness regarding the supported platforms flag, I actually inspired my META yml from the SNOVA META here:

• The generic opt implementation uses supported-platforms with all : https://github.com/vacuas/SNOVA/blob/65a4f79effd084982401286b1f92184f64a36929/liboqs/META/SNOVA_24_5_16_4_AES_META.yml#L28
• The specific avx2 implementation uses supported_platforms with platforms details : https://github.com/vacuas/SNOVA/blob/65a4f79effd084982401286b1f92184f64a36929/liboqs/META/SNOVA_24_5_16_4_AES_META.yml#L38

I guess the issue might lie within the fact that the MQOM META provides two generic implementations that can run on all platforms, hence an ambiguity about the default implementation? Then, how is it possible to include two such generic implementations leaving the choice of the one included in the compiled lib to the user at compilation time?