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. _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
