Added provisional FN-DSA implementation (2025-02-01, with ARM Cortex-…

[pornin]

FN-DSA (to-be-standardized Falcon) with M4F optimizations. This is a "provisional" FN-DSA, since the FN-DSA standard is not published yet. This PR relies on the following PR to be first imported in mupq: mupq/mupq#162
Additional M4F optimizations are imported from https://github.com/pornin/c-fn-dsa

This works on my STM32F4 Discovery board. I do not have any other M4 board to test on.

• PR changes testvectors
• Tests pass in qemu
• Testvectors pass in qemu
• Tests pass on Nucleo-L4R5ZI
• Testvectors pass on Nucleo-L4R5ZI
• Updated Benchmarks
• Updated Skiplist entries

[mkannwischer]

Tracking progress:

• Tests pass in qemu
• Testvectors pass in qemu
• Tests pass on Nucleo-L4R5ZI
• Testvectors pass on Nucleo-L4R5ZI
• Updated Benchmarks
• Updated Skiplist entries

[mkannwischer]

Thanks @pornin for contributing this! Everything works fine on my end.
I've updated the benchmarks and also removed the outdated Falcon implementations.

What's possibly a bit confusing is that you are using a local SHA-3/SHAKE implementations which results in our hashing benchmarks showing 0 cycles spent in hashing.
Maybe we can resolve that in the next iteration of the code? Either by using the pqm4 SHA-3/SHAKE implementation (if that is feasible), or by adding the profiling to your local SHA-3 implementation?

[pornin]

Switching implementation is kinda delicate; mine ensures that the output of Keccak-f is readable directly from the SHAKE buffer. Making an extra function call to do that shows up in the performance figures of verification (the hash-to-point process does that a lot). Alternatively, I could extract bytes by chunks of 136 bytes into an extra buffer, but that will increase stack usage by 136 bytes.

Adding the profiling should not be too hard, I'll check that now.