[TLS] Re: ML-KEM recommended column

"D. J. Bernstein" <djb@cr.yp.to> Sun, 08 June 2025 00:17 UTC

Date: Sun, 08 Jun 2025 00:16:48 -0000
Message-ID: <20250608001648.4085041.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: tls@ietf.org
Mail-Followup-To: tls@ietf.org
In-Reply-To: <f0425eaf-dfc5-474c-94c3-9a50f71fff22@app.fastmail.com>
Message-ID-Hash: Y67Z7F6OZEEY4PLITNKUZS2NCFIFO74I
Precedence: list
Subject: [TLS] Re: ML-KEM recommended column
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/raIaeSpfMWwVbh2FSRkkhFqXlqc>

Filippo Valsorda writes:
> 2025-06-07 19:49 GMT+02:00 Loganaden Velvindron <loganaden@gmail.com>:
> > ML-KEM implementations may suffer from compiler optimizations that could weaken
> > the security properties of a pure ML-KEM implementation such as Kyberslash.
> That is both a general risk

Indeed, even for something as traditional as ECC, we're continuing to
find implementation vulnerabilities (such as CVE-2023-6135 in Firefox;
see https://cr.yp.to/papers.html#safecurves for many more examples and
in-depth analysis). Presumably what we're now seeing from compilers (see
generally https://cr.yp.to/papers.html#cryptoint) will produce some
exploitable problems in ECC software.

> independent of the algorithm,

Wait, why would one expect every algorithm to have the same probability
of implementation vulnerabilities?

Every report tracing vulnerabilities to particular algorithm features is
evidence to the contrary. For example, we have a clear understanding of
how some curves lead to point-validation disasters while others don't.
The latest wave of compiler issues needs more study, but it would be
astonishing if this affects every algorithm equally.

What's very easy to see is that switching from ECC to PQ has a higher
probability of implementation-security disasters than using an ECC+PQ
hybrid. This isn't denying the possibility of compilers screwing up
_both_ the ECC part and the PQ part; it's saying that leaving out ECC
increases user risk. This is one of the reasons to recommend hybrids.

> and in the specific case only applicable when reusing public keys.

Regarding the three different timing leaks discovered so far in the
reference Kyber software, it's true that the first demos of key
extraction have targeted keys used many times. However, seeing that a
demo works in situation X doesn't say that the underlying vulnerability
is exploitable _only_ in situation X, never mind the whole class of
vulnerabilities.

These demos succeeded using only low-bandwidth information about the
time taken by the Kyber software. Higher-bandwidth timing channels are
known and presumably would allow attacks using fewer dec invocations,
especially in the context of hyperthreading, enclaves, etc. Maybe using
a key for just one dec is safe, but maybe not.

---D. J. Bernstein (KyberSlash coauthor but speaking for myself)

[TLS] ML-KEM recommended column Bellebaum, Thomas
[TLS] Re: ML-KEM recommended column D. J. Bernstein
[TLS] Re: ML-KEM recommended column Bellebaum, Thomas
[TLS] Re: ML-KEM recommended column Loganaden Velvindron
[TLS] Re: ML-KEM recommended column Filippo Valsorda
[TLS] Re: ML-KEM recommended column Blumenthal, Uri - 0553 - MITLL
[TLS] Re: ML-KEM recommended column Bellebaum, Thomas
[TLS] Re: ML-KEM recommended column Bas Westerbaan