KpqC SUPERCOP integration status

[D. J. Bernstein]

supercop-20240625 includes HAETAE (crypto_sign/haetae*), MQ-Sign
(crypto_sign/mqsign*), and NTRU+ (crypto_kem/ntruplus*). Benchmarks are
starting on many machines, and many results will appear within days. One
128-core machine already has results online:

https://bench.cr.yp.to/results-sign.html#amd64-rome0
https://bench.cr.yp.to/results-kem.html#amd64-rome0

In the case of crypto_sign/mqsign*, there's a tradeoff between speed and
security. I marked the slower ref software as goal-const{branch,index},
meaning that it's designed to avoid secret branch conditions and secret
array indices. The documentation also seems to indicate that the faster
avx2 software is designed to be constant-time; however, the software has
secret array indices, so I didn't mark goal-const{branch,index}. For
cases like this, SUPERCOP shows benchmarks for both, with a red "T:" for
the faster software. I wouldn't be surprised if the faster software is
exploitable; I recommend changing the multiplier to avoid using secret
array indices.

For crypto_kem/ntruplus*, the page

https://bench.cr.yp.to/web-impl/amd64-rome0-crypto_kem-ntruplus864.html

shows "Test failure" for the avx2 implementation with some compilers, an
issue that I mentioned before and that should be investigated. This type
of compiler variation is often easy to diagnose with -fsanitize=address.

The same page shows "Compiler output" with clang -mcpu=native, but that
can be safely ignored in this case: it's simply reflecting the fact that
clang -mcpu=native doesn't support AVX2.

Status of SUPERCOP integration of the other submissions:

* AIMer and SMAUG-T: My understanding is that software updates (and
spec updates for SMAUG-T) are in progress. These should be easy to
integrate into SUPERCOP once the updates are done.

* NCC-Sign: As mentioned before, the original reference code and
optimized code produce different results; this means that they
can't simultaneously pass SUPERCOP's checksums. There are also more
timing variations that need to be handled.

* Paloma: As mentioned before, I recommend rewriting the software to
use the techniques of https://eprint.iacr.org/2017/793. I think
this will give a big speedup while also eliminating some timing
variations, so I don't think the current speeds are reflecting the
speeds that users will see.

* REDOG: My understanding is that the submission team is still
working on their initial C code.

---D. J. Bernstein