>
> Even if point compression is used, one should check that the square
> root exists, unless both:
>
> 1) The invalid compressed points are guaranteed to be on the twist[1] AND
> 2) The curve is twist-secure (NIST and Brainpool aren't[2][3]).
>
I assumed that the points are uncompressed (which includes taking the square
roots) but, yes, an implementation could
use an x-coordinate latter. In this special case your observations apply.
>
> As for small subgroups, unless protocol properly hashes the public keys
> (and currently TLS does not), one should check for those[4] as those can
> cause trouble[5].
>
>
> [1] E.g.:
> - Using Montgomery X-only
> - Using Weierstrass with usual square root mod 4k+3
>
> [2] In fact, both have at least one very twist-insecure curve.
>
> [3] Most of twist-secure curves seem to also be designed for
> Montgomery X-only.
I guess this is because X-only for Weierstrass is expensive, thus either
uncompressed points are transmitted, in which
case checking the validity of the point is cheap, or points are uncompressed,
which implicitly verifies the validity.
Anyway, I'm not sure if non-Weierstras in the scope for the draft.
>
> [4] This checking is not really feasible for DH with arbitrary primes.
> (if one assumed SG, this could be done (check for -1, 0 or 1), but such
> check is wrong for non-SG primes).
>
If an implementation supports only a limited set of primes, for each prime the
required check ("co-factor" (p-1)/q could
be stored along with the primes. Of course, for q << p the check is expensive,
but necessary though.
--
Johannes
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
