Speaking for myself, not on behalf of the SPHINCS+ team (or other teams potentially relevant here).
Peter C writes: > Under realistic network conditions, TLS handshakes with full SLH-DSA > certificate chains seem to be about 5-10 times slower than traditional > certificate chains and, in some cases, can take on the order of > seconds. For, e.g., sphincsf128shake256simple, a quad-core 3GHz Intel Skylake from 2015 handles 85 signatures per second and 1300 verifications per second. (Source: dividing 12 billion cycles/second by the cycle counts given in https://bench.cr.yp.to/results-sign/amd64-samba.html.) Sure, one can come up with scenarios where this isn't fast enough or where 17KB for a signature is a problem. But there are also environments where these costs are negligible compared to the transmission and processing of user data. > not recommended for use in signature_algorithms People deploying TLS can do the performance measurements for themselves and decide whether high confidence in security is affordable for their applications. Shouldn't speed be given lower weight than security in decisions of what to recommend? If the answer is that all decisions will be made by the scenarios most sensitive to speed, so being less affordable than Dilithium (ML-DSA) is fatal, then shouldn't Dilithium be analogously excluded, given that Dilithium is less affordable than KEMs for typical authentication tasks? The point here isn't just that Dilithium is outperformed by Kyber; consider the fact that a few hundred Dilithium signatures plus a public key cost more than a few hundred McEliece ciphertexts plus a public key. Conversely, if the answer is that we should skip all of these signature systems for TLS server keys and consider them only for CA keys, then shouldn't claims about signature affordability start with data regarding how many signatures CAs are doing? ---D. J. Bernstein _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
