HN user
Damien Miller, hacker @ OpenSSH / OpenBSD / Google. Opinions are my own.
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.
caveat: IANAFA (I am not a FIPS auditor)
Those are completely disjoint threats.
A captured SSH session should never be able to decrypted by an adversary regardless of whether it uses passwords or keys, or how weak the password is.
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).
- development time to switch things over
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.
[1] https://github.com/cryspen/libcrux
- 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.
They don't endorse hybrid constructions but they also don't ban them. From the same document:
However, product availability and interoperability requirements may lead to adopting hybrid solutions.
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.
You can help by testing/reviewing https://github.com/djmdjm/openssh-wip/pull/29/commits/659cbc...
No, it's a fix. It completely removes the signal race as well as introducing a mitigation for similar future bugs
Ubuntu isn't affected _by this exploit_
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.
I'm confident that someone will make a workable exploit against 64-bit systems.
OpenSSH release notes: https://www.openssh.com/txt/release-9.8
Minimal patches for those can't/don't want to upgrade: https://marc.info/?l=oss-security&m=171982317624594&w=2
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.
It also depends on the previous one for the PING/PONG messages used to simulate keystrokes and terminal echo: https://github.com/openssh/openssh-portable/commit/dce6d80d2...
correct - this is for the post-auth session and not the authentication phase
This is completely irrelevant to password based SSH authentication. The timing obfuscation is for the session _after_ authentication.
This is irrelevant for SSH password authentication. The obfuscation is for the session _after_ authentication.
yeah, keeping the total bandwidth used to be less than a dialup modem connection was an explicit goal when choosing the 20ms default interval.
You can sign yubikey-hosted FIDO keys in OpenSSH just fine.
A FIDO token can also act as CA, though the certificates it issues will be limited to use by relatively recent SSH versions as FIDO support was only added in 2019.
Repeating this here. We (OpenSSH) have not disregarded NIST, we just added a PQ algorithm before NIST finished their competition and we'll almost certainly add support for the finalist fairly soon.
We (OpenSSH) haven't "disregarded" the winning variants, we added NTRU before the standardisation process was finished and we'll almost certainly add the NIST finalists fairly soon.
We don't ask anyone to learn CVS. People send the maintainers (myself and other) their changes (git format-patch is fine) and we integrate them.
scp isn't part of the ssh protocol. It's a command that runs over it.
actually, sftp is a bit more scriptable than scp. You can pass sftp a "batchfile" of commands and control per-command whether their success should terminate the batch.
scp wins on brevity of commandline syntax
yeah, pretty much. If someone implemented scp's command-line with sftp underneath then we could start the (slow) deprecation process.
scp only appears to have simplicity because it outsources large parts of its functionality (e.g. glob expansion) to the destination host's shell. scp/rcp was a great protocol for 1981 (yes, that's when it was introduced) but not for 2019
Unfortunately, you can't alias scp=sftp as the commandline syntax is different. I'd love someone to write a scp replacement that attempted the sftp protocol first and optionally fell back to scp if that didn't work.
For workflows, we have good tooling based around https://github.com/yasuoka/cvs2gitdump to convert OpenBSD CVS commits to git commits in a "pristine upstream" repository (https://github.com/djmdjm/openbsd-openssh-src) and merge them to the portable OpenSSH repository. Merging changes from OpenBSD to portable is usually completely painless and only a hassle when merging something really large (in LoC touched) like a refactoring.
It would certainly be easier for external contributors (and us) if OpenBSD used git natively but as OpenBSD was AFAIK the first open source project to expose a CVS tree of their work to the world there's a lot of legacy to overcome.