Re: Best practices for signature verifcation

[Soatok Dreamseeker <soatok.dhole () gmail com>]

On Thu, Jan 1, 2026 at 5:10 PM Clemens Lang <cllang () redhat com> wrote:

> Hi Simon,
>
>
> > On 31. Dec 2025, at 14:07, Simon Josefsson <simon () josefsson org> 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/