[TLS] Re: Erlang/OTP and Bouncy Castle now supporting SLH-DSA in end-entity certificates

[Yaroslav Rosomakho <[e-mail]>]

Keep in mind that Apple M-series cores perform much better than anything
else for most cryptographic operations.

x64 cores perform at least ~50% worse:
https://signatures.yaroslav.uk/#l=openssl.4.1.0&f=SLH-DSA&a=slhdsa_sha2_128s%2Cslhdsa_shake_128s&o=sign%2Cverify

(tests are limited to JOSE adopted codepoints only)

-yaroslav

On Fri, Aug 14, 2026 at 11:05 AM Viktor Dukhovni <[e-mail]>
wrote:

> On Thu, Aug 13, 2026 at 10:34:06AM +0000, John Mattsson wrote:
>
> > We constantly try to maintain an overview of what different TLS
> > libraries support, especially now that we are in the middle of the PQC
> > migration.
> >
> > While several TLS libraries have supported SLH-DSA in CA certificates
> > for some time, I’m happy to report that both Erlang/OTP [1] and Bouncy
> > Castle now support SLH-DSA as the public key in end-entity
> > certificates. They also support ML-DSA and ML-KEM. SLH-DSA performance
> > is adequate for all of our telecom use cases.
>
> Are these enabled by default, or merely available when explicitly
> configured on both ends?
>
> > Have I missed any other TLS libraries with comparable support?
>
> The signing performance of SLH-DSA makes it a generally poor choice
> for TLS on the public Internet.  Which SLH-DSA variants do you
> consider as viable for deployment in TLS?  On an Apple M3:
>
>     CPUINFO: OPENSSL_armcap=0x987d
>                          keygens/s    sign/s  verify/s
>       SLH-DSA-SHA2-128f     7050.0     300.5    4716.4
>       SLH-DSA-SHA2-192f     5055.5     164.7    3095.5
>       SLH-DSA-SHA2-256f     1845.0      77.1    2894.5
>      SLH-DSA-SHAKE-128f     1405.5      59.2    1010.0
>      SLH-DSA-SHAKE-192f      952.0      37.0     657.7
>      SLH-DSA-SHAKE-256f      359.7      17.8     684.0
>       SLH-DSA-SHA2-128s      110.0      14.4   14140.0
>       SLH-DSA-SHA2-192s       80.1       6.9    8001.5
>       SLH-DSA-SHA2-256s      116.4       6.9    5455.5
>      SLH-DSA-SHAKE-128s       22.1       2.9    2733.5
>      SLH-DSA-SHAKE-256s       22.7       1.9    1324.5
>      SLH-DSA-SHAKE-192s       14.7       1.6    1958.3
>
> The IANA code points are:
>
>
> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-signaturescheme
>
>     0x0911      slhdsa_sha2_128s        N
>  [draft-reddy-tls-slhdsa-01]
>     0x0912      slhdsa_sha2_128f        N
>  [draft-reddy-tls-slhdsa-01]
>     0x0913      slhdsa_sha2_192s        N
>  [draft-reddy-tls-slhdsa-01]
>     0x0914      slhdsa_sha2_192f        N
>  [draft-reddy-tls-slhdsa-01]
>     0x0915      slhdsa_sha2_256s        N
>  [draft-reddy-tls-slhdsa-01]
>     0x0916      slhdsa_sha2_256f        N
>  [draft-reddy-tls-slhdsa-01]
>     0x0917      slhdsa_shake_128s       N
>  [draft-reddy-tls-slhdsa-01]
>     0x0918      slhdsa_shake_128f       N
>  [draft-reddy-tls-slhdsa-01]
>     0x0919      slhdsa_shake_192s       N
>  [draft-reddy-tls-slhdsa-01]
>     0x091A      slhdsa_shake_192f       N
>  [draft-reddy-tls-slhdsa-01]
>     0x091B      slhdsa_shake_256s       N
>  [draft-reddy-tls-slhdsa-01]
>     0x091C      slhdsa_shake_256f       N       [draft-reddy-tls-slhdsa-01]
>
> The code points are easy enough to add, but I'm reluctant to enable them
> by default.  And unlike the case with supported groups OpenSSL for now
> does not have a default supported signature algorithms list that would
> exclude these if advertised as TLS signature algorithms by a "provider".
>
> So I'd probably first want to set an explicit signature algorithms list
> in the default configuration file that limits the signature algorithms
> list to a widely used "sensible" subset, before adding support for
> SLH-DSA.
>
> --
>     Viktor.  🇺🇦 Слава Україні!
>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>

-- 


This communication (including any attachments) is intended for the sole 
use of the intended recipient and may contain confidential, non-public, 
and/or privileged material. Use, distribution, or reproduction of this 
communication by unintended recipients is not authorized. If you received 
this communication in error, please immediately notify the sender and then 
delete all copies of this communication from your system.