Re: [Cfrg] Elliptic Curves - curve form and coordinate systems (ends on March 12th)

[Dan Brown <[e-mail]>]

> -----Original Message-----
> From: Adam Langley
> 
> pitfalls. Here the pitfall would be omitting to check that (u,v) is a point on the
> curve—something that sending compressed points avoids.

 [DB] Compressed points are not really what protects against bad points (though I've also forgotten that fact a few times too).  For Curve25519, the protection is from the XZ (oops UW?) coordinates, i.e. the Montgomery ladder, plus twist security. In other words, upon receiving v for ECDH, just discard v.  (* Well, maybe there's protection from the field size too, see below.)
 
Last fall, I sent CFRG an example of an order 11 compressed bad point for P256 (perhaps some people manually/automatically ignore my messages, understandably ;-)

I have not worked out the details of a similar example for Curve25519. To be applicable, some Curve25519 user would have to decompress to XYZ (oops UVW) coordinates.  I'm not aware of anybody using XYZ coordinates for Curve25519, or any good reason to do so.  But bad compressed points could probably be found for some XYZ coordinate addition rules. (* Well, I didn't check if there's a realistic bad decompression for 5 mod 8 fields, i.e. a natural way to produce false square roots).