Viewing profile — djmdjm

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 ca…

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 r…

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 pas…

>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 th…

> - 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 repla…

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…

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 gat…

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 …

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

Yes: https://github.com/openssh/openssh-portable/commit/03e3de416...

> 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 …

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 versi…

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 fina…

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.