> Any reasonable risk assessment will conclude that the probability of an exploitable arithmetic bug or timing leak or randomness-usage mistake in the UltraKEM

> Any reasonable risk assessment will conclude that the probability of an exploitable arithmetic bug or timing leak or randomness-usage mistake in the UltraKEM software is higher than the probability of such a exploit in the X25519 software. It seems strange to pit a specific classical algorithm against a general-case PQ algorithm made up for the sake of argument, it feels like a bit of a straw man. I've written hobbyist-grade implementations of both X25519 and ML-KEM-768 (aka Kyber). All other things being equal, I think arithmetic bugs in X25519 are more likely, given that it uses 255-bit integer arithmetic, requiring a custom bigint implementation if you want peak performance. Doing 255-bit arithmetic that is both fast, and provably does not contain limb overflow edge-cases (to name just one possible bug class), is hard. At the very least, it's not something I'd trust myself to be able to do. On the other hand, Kyber arithmetic all fits within standard register sizes, without needing to split things up. This doesn't make it immune from arithmetic-related issues (as KyberSlash demonstrates), but it's probably easier to get right overall. I agree that for the time being, the average X25519 impl will be significantly more trustworthy than the average Kyber implementation (or any other PQ construction), due to its maturity, but it seems dishonest to imply that PQ algorithms are inherently harder to get right. Despite this, I am broadly in favour of Hybrid schemes. It seems like the anti-hybrid stance is mostly coming from large slow-moving orgs - sucks to suck, but don't let your unagility hold the rest of us back!