Re: [TLS] Curve25519 and TLS

On Sat, Jun 14, 2014 at 4:39 AM, Viktor Dukhovni
<viktor1dane@dukhovni.org> wrote:
> On Fri, Jun 13, 2014 at 06:30:46PM -0300, Watson Ladd wrote:
>
>> TLS with ECC computes the premaster secret as H(abg) where g is the
>> generator of the group, and a and b are the ephemeral exponents.
>> Because of protocol weaknesses, this premaster secret must be
>> "contributory": neither side can be allowed to dictate it.
>>
>> Curve25519 has order 8*q, where q is some prime. All encoded public
>> keys lie on this or a twist with order 4*q'. (I might be wrong in the
>> details, but it's right enough). In particular there is a point of
>> order 2.
>
> As far as I can tell, this is not the case with Diffie-Hellman over
> Curve 25519, because the base-point (namely 9) has order 8, and
> the cyclic sub-group it generates has prime order.  All private
> keys are multiples of 8, so an attacker M who chooses a low order
> element must send a public key m of order 1, 2, 4 or 8, which since
> Alice's private exponent is a multiple of 8 means that g^{am} is
> the identity.

Yes, the only key that results is the identity. So the attack is 100%,
not 50%, effective.

>
> See the "Small-subgroup attacks" section of DJB's paper.  Since
> key agreement with Curve25519 is presumably Diffie-Hellman with
> (9) as the base point and the recommended constraints on private
> exponents, there should be no problem.

Read http://cr.yp.to/ecdh.html, the portion after "contributory behavior".

This is not an attack that recovers the exponent: it's an attack that
involves predicting the premaster secret ahead of time.
>
>> A malicious server can provide a point of order 2, and with 50%
>> probability get a dictated premaster secret.
>
> Not useful when Alice's (or Bob's depending on whom Mallory is
> trying to fool) private exponent is a multiple of 8, the only check
> required is that the final shared secret is not the identity (IIRC
> the point at infinity is represented by "0" in Curve 25519 so the
> check is then just to make sure that the DH shared secret is not
> 32 zero octets).

Yes, but this check isn't specified in the johnsson-tls-curve25519
draft. It needs to be.
Section 2.1 states
   Parties exchange  their public keys (see Section 2.3) and compute a
shared secret as x_S = Curve25519(d, x_peer).  This shared secret is
     used directly as  the premaster secret, which is always exactly
32 bytes when ECDHE  with Curve25519 is used.

That implies there is no check on the value of the shared secret.
Sincerely,
Watson Ladd

>
> Corrections/elaboration from folks more familiar with 25519 welcome.
>
> --
>         Viktor.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin