Dennis Jackson writes: > This was used by Eli Biham and Lior Neumann to break Bluetooth pairing > standard back in 2018 [1]. The Bluetooth standard previously said > implementers could choose to do full point validation or always use > ephemeral keys, and folks opted for the less complex choice. This isn't a > clear separator between X25519 and P-256 though, since X25519 would also > need to reject small order points in order to avoid the same attack.
Unless I'm confused, the attack against Bluetooth's use of P-224 relied on the fact that Bluetooth's authentication covered only x-coordinates and failed to cover y-coordinates---so the attacker was free to manipulate y-coordinates. (And, yes, of course implementors didn't check whether (x,y) was on the curve.) X25519 sends just an x-coordinate. Upgrading Bluetooth to X25519 would have simply scrapped the y-coordinate. Doesn't this mean that the full points would have been authenticated, stopping the attack? What exactly do you mean when you say "the same attack"? To be clear, looking around enough _does_ find literature on protocols that, unlike the original DH protocol, need "contributory" behavior. In those protocols, points of low order (e.g., the point at infinity, which exists on any curve and is allowed by some point encodings) have to be rejected. The very first version of the Curve25519 web page--- https://web.archive.org/web/20060210045513/https://cr.yp.to/ecdh.html ---already spelled out the list of inputs to reject for this case: How do I validate Curve25519 public keys? Don't. The Curve25519 function was carefully designed to allow all 32-byte strings as Diffie-Hellman public keys. Relevant lower-level facts: ... This is discussed in more detail in the curve25519 paper. There are some unusual non-Diffie-Hellman elliptic-curve protocols that need to ensure "contributory" behavior. In those protocols, you should reject the 32-byte strings that, in little-endian form, represent 0, 1, [various further numbers], and 2(2^255 - 19) + 1. But these exclusions are unnecessary for Diffie-Hellman. For NSA/NIST ECC, ensuring contributory behavior is considerably more error-prone: sure, the list of low-order points is shorter per curve, but people again and again fail to check whether the input (x,y) is on the curve to begin with, and then the attacker has an infinite pool of low-order points to exploit. This is also a major reason that NSA/NIST ECC keeps failing to protect the secrecy of long-term DH keys. Given how well known the oops-I-forgot-to-check failure mode is, why isn't every encryption protocol designed to just send an x-coordinate? Here are two answers: * For the NSA/NIST curves, people complain about the implementation impact of using x instead of (x,y). * Patent 6141420 (filed in 1994, expired 2014) claimed recovery of (x,y) from x and limited information about y. There's clear prior art (Eurocrypt 1992, page 171), but Certicom was scaring people for many years. Montgomery curves neatly dodge both of these issues: the Montgomery ladder never looks at y, and it's simpler and faster than any other approach. ---D. J. Bernstein _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
