Bugs happen: The easy way to compare solo PQ to ECC+PQ

Re:Bugs happen: The easy way to compare solo PQ to ECC+PQ by dhx on Saturday September 05, 2026 @12:45AM (#49573142)

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

[ Parent | on HN ]

Re:Bugs happen: The easy way to compare solo PQ to ECC+PQ by mswphd on Saturday September 05, 2026 @01:34AM (#49573378)

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

[ Parent | on HN ]