djmdjm

Entitlements are a great system for user applications, but pretty much unusable for OSS system applications as AIUI they need codesigned binaries

This was in the context of a contribution to add (IIRC) ext4 filesystem support to OpenBSD. In this case, I was worried that the AI was just regurgitating code that was in its training corpus because how many ext4 implementations are there?

I think AI generated bugfixes and smaller features that don't duplicate fairly unique pieces of work in other projects are much less problematic from a copyright perspective at least.

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).

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.

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.