Re: [Cfrg] [TLS] Curve25519 in TLS and Additional Curves in TLS

["Dan Harkins" <[e-mail]>]

On Fri, January 24, 2014 3:15 pm, Watson Ladd wrote:
> On Jan 24, 2014 2:42 PM, "Andrey Jivsov" <[e-mail]> wrote:
>>
>> On 01/24/2014 01:04 PM, Robert Ransom wrote:
>>>
>>> On 1/24/14, Andrey Jivsov <[e-mail]> wrote:
>>>>
>>>> On 01/24/2014 12:13 PM, Michael Hamburg wrote:
>>>>>
>>>>> On Jan 24, 2014, at 12:01 PM, Andrey Jivsov <[e-mail]
>>>>> <mailto:[e-mail]>> wrote:
>>>>>>
>>>>>> This should work for your suggestions to use the Elligator map,
>>>>>> assuming that I get the corresponding scalar.
>>>>>>
>>>>>> I will need access to the private m for M=mG. I assumed it is sort
>>>>>> of
>>>>>> a user static public key.
>>>>>>
>>>>>> The server side adjustments are similar.
>>>>>
>>>>> It is critical to the security of SPAKE2 that nobody can know m.
>>>>> Part
>>>>> of why Elligator is nice is that it removes the possibility that
>>>>> someone could somehow figure out m, thereby breaking the security of
>>>>> the entire system.  It is an essential security feature of Elligator
>>>>> (in this use and others) that it does not give you access to that
>>>>> discrete log.
>>>>>
>>>>> So, in other words, you can’t do this, and changing the system so
>>>>> that
>>>>> you can do this would break it.
>>>>>
>>>>> Cheers,
>>>>> — Mike
>>>>
>>>> Given that I am trusted to keep my password, why am I not trusted to
>>>> keep my m in M=m*G private?
>>>
>>> M and N are protocol parameters, and must be shared among all users.
>>>
>> I see. So the protocol allows a network of nodes where each one can be a
> server or a client. Given recent discussions on this list, the trusted 3d
> party that is generating the M,N and forgetting the m,n is better be
> really
> trusted ;-).
>
> All of this to save 32 bytes?

  No, it has nothing to do with saving 32 bytes. It has to do with making
SPAKE2 be something other than the DUAL_EC_DRBG of PAKEs (a protocol
with SUTS-- something up their sleeve).

  Dan.