Don't buy the argument, this stuff is simple enough that we can formally verify and audit it very carefully.
Additionally, NIST had the foresight to derandomize all the algorithms, so we can now check e.g. what a correct implementation will produce on particular seeds. This is a big deal because a bunch of e.g. ECDSA bugs, such as biased nonces or reused nonces, are trivally caught by such tests/derandomization.
ML-KEM encaps/decaps is very fast, as fast/faster than EC. It's large, and adding EC does not meaningfully affect the size, but it meanfully affects encaps/decaps time.
I used to be pro-hybrid but I feel much more on the fence about it nowadays.
ECC software can have flaws too but I don't think anyone seriously suggested hybridizing two different ECC implementations, for example.
Don't buy the argument, this stuff is simple enough that we can formally verify and audit it very carefully.
Additionally, NIST had the foresight to derandomize all the algorithms, so we can now check e.g. what a correct implementation will produce on particular seeds. This is a big deal because a bunch of e.g. ECDSA bugs, such as biased nonces or reused nonces, are trivally caught by such tests/derandomization.
TLDR: the bugs are going to be elsewhere.
Why don't we use hybrid RSA and ECC then? Or hybrid AES and ChaCha20?
Software bugs is a weak argument for a new hybrid standard, and doesn't justify the additional complexity.
In his defense, ECC is unusually fast compared to both RSA and current PQ
ML-KEM encaps/decaps is very fast, as fast/faster than EC. It's large, and adding EC does not meaningfully affect the size, but it meanfully affects encaps/decaps time.