DHdhx·Jul 7, 2026
This reads to me as an argument of "If you thought ECDSA was bad, wait until you see MLKEM?"
ECDSA history is repeating itself again when you consider how poorly the proposed MLKEM RFC deals with side channel resistance:
From draft-ietf-tls-mlkem-8:[1]
"Implementers are encouraged to use implementations resistant to side-channel attacks, especially those that can be applied by remote attackers."
From NIST SP 800-227:[2]
"Cryptographic modules for KEMs should be designed with appropriate countermeasures against side-channel attacks. This includes protecting against timing attacks with constant-time implementations and protecting memory from leakage. Universal guidelines are unlikely to be helpful as exposure to side-channel attacks varies significantly with the desired application, and countermeasures are often costly."
MLKEM is more compl
Read the rest
ex and has more chances of stuff-ups in implementation than ECDSA did. A single sentence of encouragement is all that is on offer from this MLKEM RFC. It doesn't even have the lightweight "Security Considerations" section which RFC8032 for EdDSA provided.[3]
As a point of reference for how hard it is to implement side channel resistant MLKEM see [4] (formal verification) and [5] (errors in formal verification). The MLKEM RFC doesn't offer a "Security Considerations" section to explain how difficult it is to implement side channel resistant MLKEM (perhaps it's easy :S), and if it were hard to implement, to recommend use of EdDSA+MLKEM for cryptography implemented on devices an attacker may be able to physically access, or when used on public networks as a workaround given that side channel resistant EdDSA would be easier to implement.
[1] https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/
[2] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...
[3] https://www.rfc-editor.org/info/rfc8032/#section-8.1
[4] https://github.com/pq-code-package/mlkem-native/tree/main/pr...
[5] https://eprint.iacr.org/2026/192
edit: added reference 5