My understanding is that a hybrid using x25519 as the classical KEM is fine on the basis that the security of the construction rests (for the purposes of approval) on ML-KEM and can't be made worse by the other part of the hybrid algorithm.
I don't have a definitive reference for this though.
FIPS certification is given to an entire "cryptographic module" that includes hardware and software. "FIPS compliant OpenSSH" is therefore a misnomer, you have to certify OpenSSH running on a particular OS on particular hardware.
FIPS compliance does require use of specific algorithms. ML-KEM is NIST approved and AFAIK NIST is on record saying that hybrid KEMs are fine. My understanding is therefore that it would be possible for mlkem768x25519-sha256 (supported by OpenSSH) to be certified.
>In light of the recent hilarious paper around the current state of quantum cryptography
I assumed that paper was intended as a joke. If it's supposed to be serious criticism of the concept of quantum computing then it's pretty off-base, akin to complaining that transistors couldn't calculate Pi in 1951.
> how big is the need for the current pace of post quantum crypto adoption?
It comes down to:
1) do you believe that no cryptographically-relevant quantum computer will be realised within your lifespan
2) how much you value the data that are trusting to conventional cryptography
If you believe that no QC will arrive in a timeframe you care about or you don't care about currently-private data then you'd be justified in thinking PQC is a waste of time.
OTOH if you're a maintainer of a cryptographic application, then IMO you don't have the luxury of ignoring (2) on behalf of your users, irrespective of (1).
This is a one time cost, and generally the implementations we're switching to are better quality than the classical algorithms they replace. For instance, the implementation of ML-KEM we use in OpenSSH comes from Cryspen's libcrux[1], which is formally-verified and quite fast.
> - more computation, and thus more energy, because PQC algorithms aren't as efficient as classical ones
ML-KEM is very fast. In OpenSSH it's much faster than classic DH at the same security level and only slightly slower than ECDH/X25519.
> - more bandwidth, because PQC algorithms require larger keys
For key agreement, it's barely noticeable. ML-KEM public keys are slightly over 1Kb. Again this is larger than ECDH but comparable to classic DH.
PQ signatures are larger, e.g. a ML-DSA signature is about 3Kb but again this only happens once or twice per SSH connection and is totally lost in the noise.
Yeah, key agreement in the context of SSH is quite forgiving of timing side channels as SSH uses ephemeral keys. There's no prospect of repeatedly re-doing the key agreement to gather more statistics on the counterparty's timing.
Theo de Raadt made an, I think, cogent observation about this bug and how to prevent similar ones: no signal handler should call any function that isn't a signal-safe syscall. The rationale is that, over time, it's too way easy for any transitive call (where it's not always clear that it can be reached in signal context) to pick up some call that isn't async signal safe.
> The possible downgrade is usually limited to downgrading SHA2 to SHA1 when using RSA keys for user authentication
AFAIK this downgrade is not possible for OpenSSH, as it refuses RSA/SHA1 signatures by default at both the client and server. Moreover, deleting the EXT_INFO message would only remove the _advertisement_ that these messages are accepted and would change the fact of whether they are.
It might be possible to use this attack to trick an old client to making a RSA/SHA1 signature where it might mormally have made an RSA/SHA2 one, but I can't see any security impact from this as the signed data is still bound to the connection instance and it wouldn't change whether the peer would accept it anyway.
I don't have a definitive reference for this though.