Re: [TLS] draft-ietf-tls-curve25519-01 and the X25519 significant bit.

[Brian Smith <[e-mail]>]

Adam Langley <[e-mail]> wrote:

> On Tue, Dec 22, 2015 at 3:15 PM, Brian Smith <[e-mail]> wrote:
> > I still think there is value in requiring senders to send their public
> value
> > in the "normalized" form and for allowing (if not requiring) receivers to
> > reject, at least, public values >= q, for the reasons I gave in my
> previous
> > email. Ideally that would happen in the CFRG document. But, what is the
> > status of the CFRG document? I've heard that it's past the point where
> > changes will be accepted.
>
> The CFRG document is in AUTH48 right now so, indeed, it's probably too
> late for that sort of change.
>
> To give some background about why the CFRG document ended up the way it
> did:
>
> The curve25519 paper only mentions the extra bit to say: "Note that
> Curve25519 is not surjective: in particular, its final output bit is
> always 0 and need not be transmitted." [1]. It didn't specify whether
> it should be ignored or not and implementations started to differ on
> that point.


Does that matter, though? The CFRG document doesn't allow the sender to set
the high bit to 1, right? In particular, it says "All calculations are
performed in GF(p), i.e., they are performed modulo p." and "For X25519,
the unused, most-significant bit MUST be zero."

If the receiver can detect that the sender is non-conforming, then it
should be able to stop talking to it on that basis alone.


> Also, in order to keep the code simple, it didn't check
> for values >= 2^255-19. Both because that could be more code in the
> primitive itself, and because it would mean that the function would
> change from being total to partial.
>

I think there is value in it being a total function. But, I think there is
value in checking the conformance of the sender in the receiver. Note that
such a check can be layered on top of the X25519 primitive.

No implementations rejected values >= 2^255-19 from what I recall.
>

I do have a private implementation that does this check, not just for
X25519 but for basically all ECC calculations. I don't want to have to make
Curve25519 special in allowing non-canonical/non-reduced values when all
the rest of my code doesn't allow such cases, especially when the CFRG spec
already forbids implementations from sending the non-canonical/non-reduced
values.

>
> Since the CFRG has standardised Curve25519, in practice the existing
> implementations will seed the implementation ecosystem. Changing
> something really subtle like the extra bit behaviour, or rejecting
> oversized values, without a clear need, doesn't seem to me to be
> worthwhile (or, perhaps, even achievable for a spec).
>

As long as senders conform to the spec, they will not notice what the
receiver does regarding this.

Cheers,
Brian
-- 
https://briansmith.org/