[curves] curve25519 public keys with high bit set

[CodesInChaos]

On Wed, Jun 4, 2014 at 4:36 PM, Watson Ladd <watsonbladd at gmail.com> wrote:
> On Wed, Jun 4, 2014 at 7:06 AM, CodesInChaos <codesinchaos at gmail.com> wrote:
>> No matter which way is chosen, it's important to get the IETF TLS
>> specification for Curve25519 to match what's chosen and to include
>> test-vectors for it.
>
> Please, please try to follow the CFRG: that's where this specifying is
> going on. If they get it right we are happy.
> If not, we aren't. Anyone can contribute: it really does matter.

I mentioned this issue on the CFRG list on March 3rd in the email
Trevor linked in the OP.

In April the draft was updated to say that any public key with the
with the last bit set SHOULD be rejected to avoid different
interpretations in different implementations.

In the context of ephemeral TLS keys that's a reasonable restriction,
but in many other contexts it's better to accept all 32 byte values
and interpret them consistently.

I guess we don't need to care about TLS when deciding how to treat the
high bit since it should always be zero in that context.

> The only detail/problem is that you have to mask the top bit of
> generated shared keys.

Every implementation I know uses the x coordinate in montgomery form
as shared secret. This never has the top bit set.

>  This complicates exposing a simple scalarmult operation.

I think we need separate scalarmult and scalarmult-x operations
anyways in order to take advantage of x-only montgomery ladders.

I know no constant time, variable base scalar multiplication
implementations that include the sign bit, even in Edwards form.

> I'm hard pressed to think of a situation where you don't know if you
> are doing ECDH or signatures.

There are a bunch of protocols which would like to use the same long
term key for both DH based authentication (in a protocol like CurveCP,
Noise or the OTR variant TextSecure uses) and signatures.