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

On Jan 24, 2014 2:42 PM, "Andrey Jivsov" <crypto@brainhub.org> wrote:
>
> On 01/24/2014 01:04 PM, Robert Ransom wrote:
>>
>> On 1/24/14, Andrey Jivsov <crypto@brainhub.org> wrote:
>>>
>>> On 01/24/2014 12:13 PM, Michael Hamburg wrote:
>>>>
>>>> On Jan 24, 2014, at 12:01 PM, Andrey Jivsov <crypto@brainhub.org
>>>> <mailto:crypto@brainhub.org>> 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?

>
> The solution then is the "black box" one. Generate x randomly until the X
= xG + h(pass)M is a compliant point. The expected number of tries should
be 2. (sec
http://tools.ietf.org/html/draft-jivsov-ecc-compact-03#section-4.2.1 but
the criterion is for X, not xG )
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg