[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <73556662-274E-40A3-A08E-37C23D7F321B@redhat.com>
Date: Mon, 5 Jan 2026 14:45:32 +0100
From: Clemens Lang <cllang@...hat.com>
To: Demi Marie Obenour <demiobenour@...il.com>
Cc: oss-security@...ts.openwall.com
Subject: Re: Best practices for signature verifcation
Hi,
> On 3. Jan 2026, at 22:29, Demi Marie Obenour <demiobenour@...il.com> wrote:
>
> On 1/1/26 15:41, Clemens Lang wrote:
>> 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.
I agree that most open source developers will not (I would even argue *should not*) choose anything to satisfy US government rules.
However, OpenPGP is also used for package signing in Linux distributions, and a few of those will care about this use case. All I’m saying is any alternative to OpenPGP that ignores these requirements will face adoption challenges. And yes, I know crypto agility has pitfalls when done wrong — but always just using ed25519 doesn’t cut it, either.
> 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.
While I agree on technical merit, I don’t think the US government will care. It has taken years for FIPS to accept EdDSA. We’re talking decades, or more likely never, for ChaCha20-Poly1305 or Argon2. In the meantime, distributions that have users in the US public sector will probably just stay on OpenPGP.
> 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.
Algorithms published in FIPS are by definition acceptable for the US public sector. So is being in FIPS now bad or good?
> - Not being vulnerable to timing side-channels.
How do you propose we show the absence of timing side-channels? And why haven’t we done that for the last 20 years when side channels kept popping up left and right? And does that novel approach also cover power 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.
There’s even a US senator pushing NIST to allow Wireguard [1], but as things stand today, the US public sector cannot use it.
Note that this only affects a subset of Red Hat's customers, and RHEL does package Wireguard, so I wouldn’t say that people and organizations that push new algorithms and protocols are poorly represented.
Look, I don’t like these US special cases, either, and NIST is too slow in adopting better algorithms (in the case of password-based key derivation functions, I’d even argue dangerously so). If we want a better replacement for OpenPGP, we should just have all requirements on the table. I just don’t want anybody to be surprised down the road when Amazon Linux, OpenSUSE or Azure Linux stay on OpenPGP.
[1]: https://www.wyden.senate.gov/imo/media/doc/Wyden%20Letter%20to%20NIST%20Re%20Gov%20Use%20of%20Secure%20VPNs.pdf
--
Clemens Lang
RHEL Crypto Team
Red Hat
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
