On Sunday, 3 November 2024 22:22:52 CET, Peter C wrote:
John Mattsson wrote:
”Conversely, the fast version prioritizes speed over
signature size, minimizing the time required to generate
and verify signatures.”
This is incorrect. The “f” versions only have faster key
generation and signing. They have slower verification.
Also:
“This document specifies the use of the SLH-DSA algorithm in
TLS at three security levels. It includes the small (S) or
fast (F) versions of the algorithm and allows for the use of
either SHA-256 [FIPS180] or SHAKE256 [FIPS202] as the hash
function.”
The SHA2 parameter sets for security categories 3 and 5 use a
mixture of SHA-256 and SHA-512. This means that you probably
want to rename the SignatureScheme entries to
enum {
slhdsa128s_sha2 (0x0911),
slhdsa128f_sha2 (0x0912),
slhdsa192s_sha2 (0x0913),
slhdsa192f_sha2 (0x0914),
slhdsa256s_sha2 (0x0915),
slhdsa256f_sha2 (0x0916),
...
} SignatureScheme;
I think I'd go as far as make them follow the OID naming:
* slhdsa_sha2_128s
* slhdsa_sha2_128f
* ...
* slhdsa_shake_128s
* ...
as placing the hash at the end can be confusing, and indicate that's what
is used to hash the signed message in TLS, which is not the case; the
whole name specifies the public algorithm type, just like with Ed25519
--
Regards,
Alicja (nee Hubert) Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
