Daniel Van Geest <[email protected]> writes:
> Some thought on whether the small or fast versions would be more > appropriate for TLS could help then the codepoints to a reasonable > number. That is a good observation about SLH-DSA generally, and I agree some guidance on how to pick the right variant can help people deploying it. Below is my personal decision flow chart for picking SLH-DSA variant. Can others share their thinking of SLH-DSA variant choices? Is SHAKE available in your environment and its performance is acceptable? YES: go with SHAKE variants NO: go with SHA2 variants Is ~20x faster/cheaper signing more important than making verification ~3x slower/expensive? YES: go with fast variants NO: go with slow variants Do you consider AES-128 security levels acceptable? YES: go with 128 variants NO: chose 256 variants There are exceptions to those simple rules. I've experienced a situation where _both_ SHA2 and SHAKE were available, which I suppose is rather common, but the significant performance increase with SHA2 made it possible to get a ~7x improvement of verification speeds over any slow/fast combination with SHAKE. In that situation the final choice was between SHAKE-fast (because SHAKE-slow signing would be a bottleneck) and SHA2-slow (which had acceptable signing performance), and for me SHA2-slow won because the ~7x verification speed improvement became the deciding factor. /Simon
signature.asc
Description: PGP signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
