Rendered at 17:03:15 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
Retr0id 4 hours ago [-]
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.
rot256 50 minutes ago [-]
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.
libeclipse 4 hours ago [-]
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.
pona-a 3 hours ago [-]
In his defense, ECC is unusually fast compared to both RSA and current PQ
rot256 55 minutes ago [-]
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.
ECC software can have flaws too but I don't think anyone seriously suggested hybridizing two different ECC implementations, for example.
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.
Software bugs is a weak argument for a new hybrid standard, and doesn't justify the additional complexity.