[TLS] Re: Working Group Last Call for Post-quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

["D. J. Bernstein" <[e-mail]>]

Filippo Valsorda writes:
> Do any of those attacks work against implementations that don't reuse
> ephemeral key shares (which thankfully are most of them now, to the
> point we've been discussing finally making it a MUST)?

Treating P-256 etc. as fragile options where each key is used at most
once would certainly have blocked some attack demos. However, a big part
of the implementation problem with P-256 comes from how P-256 ends up
encouraging timing variations in software. That isn't something where
one-time keys are magically protected against attacks.

Sure, typical timing-attack demos are against reused keys. That's
because those are the easiest attacks to develop and demonstrate. It's a
big mistake to leap from limitations of a demo to the assumption that
anything not broken by the demo is safe. Where's the literature _trying
and failing_ to break this assumption?

The occasions where researchers have publicly studied attacks against
one-time keys end up indicating that this isn't a reasonable assumption.
For example, https://arxiv.org/abs/2502.09864 says "By targeting the
SECCURE cryptographic utility and monitoring the scalar multiplication
process, we successfully recover the secret nonce scalar from a single
trace, and thus the private key." That's for ECDSA with P-256, but it's
not reasonable to expect ECDH with P-256 to be more secure: the attack
recovers "the sequence of elliptic curve point doubles and additions".

The paper ends by noting that mitigations "are well-understood at the
software level---using constant-time software engineering practices,
where all code and data addresses are assumed to be public in the threat
model". Implementations are less likely to do this right for P-256 ECDH
than for X25519.

> criteria in the "safecurves" webpage, last updated in 2017

https://cr.yp.to/papers.html#safecurves is from 2024 and comes to the
same conclusions. Some of the vulnerability announcements covered there
are particularly striking because they're for software that supports
P-256 _and_ Curve25519, with the vulnerability being only for P-256.

> irrelevant to authenticated ephemeral ECDH

This is not true, even if "ephemeral" is conflated with "one-time". See
above regarding timing attacks.

> the many cofactor attacks against Curve25519-based cryptosystems

The word "based" is doing a lot of work here, as is a lack of definition
of "many", as is selection bias. It's not as if random protocols based
on P-256 are magically secure in reality: on the contrary, building on
shaky foundations causes one collapse after another, as we already see
in the most important ECC protocols, namely DH and signatures.

Yes, looking at enough protocols finds people screwing up the handling
of cofactors, but the right way to handle those protocols is to provide
a prime-order group on top of Curve25519.

---D. J. Bernstein


===== NOTICES REGARDING IETF =====

It has come to my attention that IETF LLC believes that anyone filing a
comment, objection, or appeal is engaging in a copyright giveaway by
default, for example allowing IETF LLC to feed that material into AI
systems for manipulation. Specifically, IETF LLC views any such material
as a "Contribution", and believes that WG chairs, IESG, and other IETF
LLC agents are free to modify the material "unless explicitly disallowed
in the notices contained in a Contribution (in the form specified by the
Legend Instructions)". I am hereby explicitly disallowing such
modifications. Regarding "form", my understanding is that "Legend
Instructions" currently refers to the portion of

    https://web.archive.org/web/20250306221446/https://trustee.ietf.org/wp-content/uploads/Corrected-TLP-5.0-legal-provsions.pdf

saying that the situation that "the Contributor does not wish to allow
modifications nor to allow publication as an RFC" must be expressed in
the following form: "This document may not be modified, and derivative
works of it may not be created, and it may not be published except as an
Internet-Draft". That expression hereby applies to this message.

I'm fine with redistribution of copies of this message. There are no
confidentiality restrictions on this message. The issue here is with
modifications, not with dissemination.

For other people concerned about what IETF LLC is doing: Feel free to
copy these notices into your own messages. If you're preparing text for
an IETF standard, it's legitimate for IETF LLC to insist on being
allowed to modify the text; but if you're just filing comments then
there's no reason for this.