Re: Best practices for signature verifcation

[Demi Marie Obenour <demiobenour () gmail com>]

On 1/1/26 15:41, Clemens Lang 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.

I think I understand the constraints you are operating under.  However,
I do not believe most open source developers and cryptographers
will choose to operate within these constraints.  In my experience,
most of them are more concerned about security and ease of use
and implementation.  OpenSSL has a reputation for difficult to use
securely, and my experience is that libraries like libsodium, the Go
cryptographic libraries, or the RustCrypto crates are preferred.

Personally, I don't see cryptographers and open source developers
becoming more interested in complying to FIPS 140, CNSA, and similar
requirements.  I suspect that a better approach would be to change
the requirements to those necessary for actual security.  These could
include things like:

- Only using algorithms that have been published in a reputable
  location, such as FIPS or a (possibly informational) IETF RFC.
- Only using algorithms that are widely used.  This could mean they
  are used by a large number of protocols, a single widely-deployed
  one, or somewhere in between [^1].
- Passing a set of test vectors.
- Not being vulnerable to timing side-channels.
- For implementations that are meant to withstand physical attacks,
  not being vulnerable to power or EM side-channels.

> Any solution that hopes to be widely adopted should be able to address those, if necessary through cryptographic 
> agility.
WireGuard is a very widely adopted counterexample.  It is used by
TailScale and many commercial VPN providers.  I suspect that the
individuals and companies that push new cryptographic algorithms and
protocols are very poorly represented among Red Hat's customers.

[^1]: There are proposals for a post-quantum version of WireGuard that
      use non-standard IND-CPA KEMS.  IND-CPA is sufficient for the
      use-case, and these versions are strictly stronger (as measured
      by the difficulty of the underlying lattice problem) than the
      version that was submitted to the NIST competition.  They are
      chosen because the WireGuard handshake must fit in a single UDP
      packet, and these have smaller public key and ciphertext sizes.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

Attachment: OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature