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

[Brian Smith <[e-mail]>]

Adam Langley <[e-mail]> wrote:

> Currently
> https://tools.ietf.org/html/draft-ietf-tls-curve25519-01#section-2.3
> says that implementations SHOULD reject inputs with the high-bit set.
> I think that should be dropped. The X25519 function is specified in
> terms of bytes in draft-irtf-cfrg-curves and I think the TLS spec
> should just use that draft.


First, maybe I'm overlooking something obvious, but I'm not seeing it: Why
are we concerned only with whether the high bit has been set, instead of
whether the public value has been reduced mod q (q == 2^255-19)? Aren't
there ~19 interesting values that don't have the high bit set but which are
also relevant to this issue?

The draft notes that if the sender calculated the result correctly, then
the result will never have the high bit set. So, then, we should have a
requirement on the sender that the sender MUST NOT send a representation of
its public value that has the high bit set? And, more generally, the sender
MUST NOT send a representation of its public value that isn't reduced mod
q. Would this be problematic to add this requirement?

If we added the above requirement on senders, then it would matter less
whether receivers reject values that aren't reduced mod q, as a conforming
implementation would never send them, right?

It seems like a good idea to reject non-reduced public values because:

1. By the argument in section 2.3, a conforming sender would never send
them, so if the sender did send one, it means there's a problem with the
sender of unknown severity, or an unknown attack on the wire. Either way,
it's safest to bail out early.

2. Rejecting non-reduced values allows us to compare keys (after
validation) by bytewise comparison and/or comparison of secure hashes of
the bytes. AFAICT, this seems to matter less for x25519 and ECDH in general
than it matters for signatures, but I bet that is just because I'm not
creative enough to discover why it might matter for ECDH. I did give an
example of why it can matter for signature public keys in [1]. It seems
better to me to be cautious on the topic.

[1] https://code.google.com/p/chromium/issues/detail?id=522228#c9

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