djb provided a link in his blog post to a long history of ECDSA side channel vulnerabilities in ECDSA implementations.[1] It's not that RSA implementations weren't prone to side channel vulnerabilities either[2], but more with EdDSA/X25519, side channel vulnerabilities have finally been largely addressed through design and standardisation, and now PQC proponents are reversing this gain and repeating the mistakes of ECDSA and ignoring side channel vulnerabilities in design and standards.
What's more likely right now:
- Your cryptosystem is compromised at some point in the future if/when quantum computers exist and can effectively attack EdDSA/X25519. Something no one has yet demonstrated or come close to demonstrating.
- Someone implementing PQC in a library/software/hardware follows the standard which does not care at all about side channel resistant implementation of critical algorithms, resulting in your private keys being leaked. Demonstrated repeatedly over 20+ years.
eh, lattice-based stuff is the first time public-key crypto can use word-size arithmetic, vs full bigint (RSA), or "just" 256+bit arithmetic. it's significantly easier to get right in a side-channel resistant way.
this isn't to say everything will go perfect, but the people doing implementations are more experienced now, and the problem is an easier one to do (though in a certain sense, optimizing compilers are making any side-channel resistance a harder goal to achieve. an implementation that is resistant under one compiler version may not be resistant in the future).
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.
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.
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.
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.
djb provided a link in his blog post to a long history of ECDSA side channel vulnerabilities in ECDSA implementations.[1] It's not that RSA implementations weren't prone to side channel vulnerabilities either[2], but more with EdDSA/X25519, side channel vulnerabilities have finally been largely addressed through design and standardisation, and now PQC proponents are reversing this gain and repeating the mistakes of ECDSA and ignoring side channel vulnerabilities in design and standards.
What's more likely right now:
- Your cryptosystem is compromised at some point in the future if/when quantum computers exist and can effectively attack EdDSA/X25519. Something no one has yet demonstrated or come close to demonstrating.
- Someone implementing PQC in a library/software/hardware follows the standard which does not care at all about side channel resistant implementation of critical algorithms, resulting in your private keys being leaked. Demonstrated repeatedly over 20+ years.
[1] https://cr.yp.to/papers/safecurves-20240809.pdf#chronology
[2] https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf
eh, lattice-based stuff is the first time public-key crypto can use word-size arithmetic, vs full bigint (RSA), or "just" 256+bit arithmetic. it's significantly easier to get right in a side-channel resistant way.
this isn't to say everything will go perfect, but the people doing implementations are more experienced now, and the problem is an easier one to do (though in a certain sense, optimizing compilers are making any side-channel resistance a harder goal to achieve. an implementation that is resistant under one compiler version may not be resistant in the future).
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.
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.