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

Andrey Jivsov <crypto@brainhub.org> Fri, 24 January 2014 22:42 UTC

Return-Path: <crypto@brainhub.org>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91D2C1A010A for <cfrg@ietfa.amsl.com>; Fri, 24 Jan 2014 14:42:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Level:
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_12=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87hiU-fGY1-k for <cfrg@ietfa.amsl.com>; Fri, 24 Jan 2014 14:42:21 -0800 (PST)
Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:32]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAA51A01E6 for <cfrg@irtf.org>; Fri, 24 Jan 2014 14:42:21 -0800 (PST)
Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta03.emeryville.ca.mail.comcast.net with comcast id HwGP1n0010lTkoCA3yiLCi; Fri, 24 Jan 2014 22:42:20 +0000
Received: from [127.0.0.1] ([71.202.164.227]) by omta04.emeryville.ca.mail.comcast.net with comcast id HyiJ1n00G4uhcbK8QyiJ9e; Fri, 24 Jan 2014 22:42:19 +0000
Message-ID: <52E2EB11.5030409@brainhub.org>
Date: Fri, 24 Jan 2014 14:37:05 -0800
From: Andrey Jivsov <crypto@brainhub.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Robert Ransom <rransom.8774@gmail.com>
X-Priority: 5 (Lowest)
References: <87ob3456s1.fsf@latte.josefsson.org> <CABqy+spt7BYqjsqLAkZssGp3aY9M+iLqV+pmyr7ZN-TXmJJpVg@mail.gmail.com> <52E060D0.9030801@polarssl.org> <CABqy+spJoswrPovxf18QS1SGdk6K=mfny6joJm3X24Vh65oagQ@mail.gmail.com> <52E0E241.40406@polarssl.org> <CABqy+sqs31ATDWJSum55m1o5pRvw8Wq5GtB-mF-hgP2emB5eFQ@mail.gmail.com> <CABqy+sozYSOTh7pbUS2GXf=4kYV3zgztXZBa10Bx=s-N8zHHyA@mail.gmail.com> <CABqy+soSojSMfx=yU9eFhmAeuJaJ_r=4h=RDR6JtOchYZ9zsQA@mail.gmail.com> <52E1BAE0.8060809@brainhub.org> <2311ADE0-B85D-4EEA-A675-03ED3735DE1D@shiftleft.org> <52E208AD.2020100@brainhub.org> <0F98B193-910E-430B-A5DF-4F72A3D9C6EC@shiftleft.org> <52E2C6A2.1010403@brainhub.org> <98B78561-8357-4636-ADA7-1A55FE32C491@shiftleft.org> <52E2CAC9.2080100@brainhub.org> <CABqy+sp0dKL3iCimRuDOrV_k229UH3tm5n=sFQ8i3DnUjSastw@mail.gmail.com>
In-Reply-To: <CABqy+sp0dKL3iCimRuDOrV_k229UH3tm5n=sFQ8i3DnUjSastw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1390603340; bh=tgGqmRVtUii5Q45DuUy4q/dLefN4meaYmZeKtx/UR5w=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=qNekE+W/l6f4IhlA4IGgON/N9CImnyVeyeprlqDa0GaGV6fBwmpVjDmnssemY+S+T Ylyk2O+TrTKVu0z9XE25fGI/OAkyEZNlRhDW9vHuvV5rIHmfLBCw3kFxUJTTMyvm2t Hl49dGygt2zlMgsuHusDXcShVRNwizY8hnJLjmCsmo9N3eAkvPQHdVuTYypAL6UEZz HDCcxV9l/pZjAtyKto1dIMnI5KxEYK7NXdIvtrbtqlMwHJhX1It34KgY+GJdzWuKjC KD+ODWEiMwApBtk/iRfmDb0eBi7Emgk87G7bNG18mhcvzixbScKknQmACBP7J26PvD 7KGt6X+cvHJMQ==
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] [TLS] Curve25519 in TLS and Additional Curves in TLS
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jan 2014 22:42:22 -0000

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 ;-).

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 )