[g-b-r]

"two timing leaks, KyberSlash1 and KyberSlash2, in every official reference Kyber implementation from 2017 through late 2023"

Cryptographers can be good, bad, be more or less knowledgeable about applied cryptography, and possibly have agendas.

[tptacek]

Huh, seen through that light, it's much clearer why we should all have ECC in our cryptosystems, because nothing has ever gone wrong with an ECC implementation.

[g-b-r]

We do all have ECC in our cryptosystems right now, and given how long it's been there, we can rely on its security much more than something new.

[tptacek]

So clearly when I go look back at the archives of Bernstein discussing 25519, I'm going to see him advocating for FFDH/25519 cascades, right?

(If my subtext wasn't clear, by the way: the implementation history of ECC is godawful.)

[g-b-r]

Was FFDH considered safe?

> the implementation history of ECC is godawful

You do know that new cryptographic code can be godawful, then?

[dhx]

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 complex 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

[eqvinox]

> A single sentence of encouragement is all that is on offer from this MLKEM RFC.

The draft only specifies the MLKEM binding into TLS; it'd be out of scope for it to go into detail on implementation considerations for MLKEM. Those would belong in or adjacent to FIPS 203 (the actual MLKEM specification).

> It doesn't even have the lightweight "Security Considerations" section which RFC8032 for EdDSA provided.[3]

It's actually RFC8032 that this criticism would apply to, since it is actually specifying EdDSA, not just referencing it externally.

[dhx]

The draft considers FIPS 203 to be normative. Therefore FIPS 203 forms part of this draft. You can't implement this draft without first implementing FIPS 203.

FIPS 203 doesn't care about side channel resistance, per my other comment at [1]. And this draft doesn't do anything to tighten the constraints on how FIPS 203 should be implemented to provide side channel resistance.

[1] https://news.ycombinator.com/item?id=48811887