Niels Möller nisse@lysator.liu.se writes:
But there are still some bugs, and it would be help a lot both for actual debugging and for confidence, to have authoritative test vectors.
I found some (authoritative?) test vectors at https://github.com/usnistgov/ACVP-Server/blob/master/gen-val/json-files, and using these, I've got sha2 signatures to pass tests.
Benchmarks, with and without sha_ni acceleration:
$ ./examples/hogweed-benchmark slh-dsa name size sign/s verify/s slh-dsa-shake-s 128 0.81 1070.48 slh-dsa-shake-f 128 21.77 365.32 slh-dsa-sha2-s 128 7.46 7491.89 slh-dsa-sha2-f 128 152.9 2447.6
$ NETTLE_FAT_OVERRIDE=none ./examples/hogweed-benchmark slh-dsa name size sign/s verify/s slh-dsa-shake-s 128 0.81 1072.95 slh-dsa-shake-f 128 21.76 365.19 slh-dsa-sha2-s 128 2.14 2151.41 slh-dsa-sha2-f 128 44.41 723.80
So it appears the sha2 variants are faster than shake, even without hardware acceleration.
It's also interesting (but not surprising, if you think about it) that the "s" (small) variants with smaller signature size are much faster to verify, compared to the "f" (fast) variants. The "f" parameters are chosen to make the *signing* operation faster. The signing operation produces a bunch of merkle tree inclusion proofs, which needs traversal of all leaves in each of the affected merkle trees. While the verify operation only needs to verify that proof, essentially a single hashing operation per height 16 bytes of the signature (ok, a few more for the wots signatures), so it scales linearly with signature size.
For comparison, on the same machine I get
name size sign/s verify/s eddsa 255 24804.6 6615.7
So with sha_ni acceleration, verifying slh-dsa-sha2-128s is sligthly faster than verifying ed25519. While signing is several orders of magnitude slower.
The code is pushed to the wip-slh-dsa-sha2-128s branch.
Regards, /Niels