On Thu, Jan 1, 2026 at 5:10 PM Clemens Lang <[email protected]> wrote:
> Hi Simon, > > > > On 31. Dec 2025, at 14:07, Simon Josefsson <[email protected]> wrote: > > > > I believe that Ed25519+SLH-DSA is the best > > near-term PQ variant for long-term software protection, alas no > > practical tools offers this today. > > SLH-DSA relies on the security of hashes, which I think we understand > pretty well, so I’m not sure we need a hybrid with SLH-DSA. But then again, > an Ed25519 pub key and signature are minuscule compared to SLH-DSA, so > maybe that doesn’t matter. > > Note that there are some outside requirements that at least companies will > not be able to ignore: > > - CNSA 2.0 (relevant for US government customers) does not allow SLH-DSA, > only ML-DSA > - Common Criteria certification requires elliptic curves >= 384 bits or > RSA >= 3072 bits, ruling out ed25519 > - use of FIPS-certified primitives (historically a problem for solutions > implemented in Go, or shipping their own implementation instead of re-using > OpenSSL, for example) > > Some of these rule out signify, for example. > > Any solution that hopes to be widely adopted should be able to address > those, if necessary through cryptographic agility. > > > -- > Clemens Lang > RHEL Crypto Team > Red Hat > Please be very careful with "cryptographic agility". Too many designs follow JWT's example of letting the attacker specify the algorithm, and then either allow "none" as a choice or mix symmetric and asymmetric modes in the same feature. https://soatok.blog/2022/08/20/cryptographic-agility-and-superior-alternatives/
