Hi, > On 3. Jan 2026, at 22:29, Demi Marie Obenour <[email protected]> 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
