Re: [Cfrg] big-endian short-Weierstrass please

"Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu> Thu, 29 January 2015 19:49 UTC

Return-Path: <prvs=9471f473ec=uri@ll.mit.edu>
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 2A6F61A00FA for <cfrg@ietfa.amsl.com>; Thu, 29 Jan 2015 11:49:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.207
X-Spam-Level:
X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham
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 mnstgROhKZb9 for <cfrg@ietfa.amsl.com>; Thu, 29 Jan 2015 11:49:18 -0800 (PST)
Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA471A00C5 for <cfrg@irtf.org>; Thu, 29 Jan 2015 11:49:18 -0800 (PST)
Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t0TJjtav019082; Thu, 29 Jan 2015 14:49:15 -0500
From: "Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu>
To: Phillip Hallam-Baker <phill@hallambaker.com>, Watson Ladd <watsonbladd@gmail.com>
Thread-Topic: [Cfrg] big-endian short-Weierstrass please
Thread-Index: AdA6QfeHnVWfJGNlTzek7rmrn4E15gBEvvUAAAkmA5D///TDAIAACxgA//+0JACAAW5uAP//wsgngABbjQD//8TFAA==
Date: Thu, 29 Jan 2015 19:46:49 +0000
Message-ID: <D0EFF650.2058C%uri@ll.mit.edu>
References: <810C31990B57ED40B2062BA10D43FBF5D42BDA@XMB116CNC.rim.net> <87386ug2r7.fsf@alice.fifthhorseman.net> <810C31990B57ED40B2062BA10D43FBF5D4413B@XMB116CNC.rim.net> <87r3ueedx7.fsf@alice.fifthhorseman.net> <20150128231006.GJ3110@localhost> <D0EED79E.204B1%uri@ll.mit.edu> <878ugleei5.fsf@alice.fifthhorseman.net> <CAMm+LwhD8ZmuO7_OsGYX_VARYT=gDJSkZVavxXkTOvfFLJ-Usg@mail.gmail.com> <CACsn0ckb4xW7gTP4m9BHkQe-Y00Y306wOcuEoSQ25XLeXX14UQ@mail.gmail.com> <CAMm+LwixbMKC+JYRJv2chgBG=dkgqxTNyDY4WZYbKQNzk6isaw@mail.gmail.com>
In-Reply-To: <CAMm+LwixbMKC+JYRJv2chgBG=dkgqxTNyDY4WZYbKQNzk6isaw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.7.141117
x-originating-ip: [172.25.177.187]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha256"; boundary="B_3505387604_815432"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-01-29_06:2015-01-29, 2015-01-29, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1501290192
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/Icjol4333372v4uF8j9iwdnmEqc>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] big-endian short-Weierstrass please
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: Thu, 29 Jan 2015 19:49:21 -0000

> On Thu, Jan 29, 2015 at 12:50 PM, Watson Ladd <watsonbladd@gmail.com> wrote:
>>> > More importantly, I can't use your curves unless you can prove to me that
>>> they are secure. And the fact we are having trouble doing that in this group
>>> proves that it is not possible to achieve that in a protocol.
>> 
>> We are not having trouble with that  in this group. Nobody disputes that any
>> of the proposed curves are secure, or the details of generation…

No, in this group we don’t seem to be having trouble with that. But I’m sure
NIST did not have any trouble with security of their selected curves.
Likewise, BRAINPOOL didn’t seem to worry about security of theirs (ask
Tanja, she was there :), DJB is certain of his curves, etc.

See my point? How would you convince others that BRAINPOOL might have had
something up their collective sleeve, but you don’t?
>> What I meant is that we had great difficulty in choosing curve parameters
>> that were not suspect so we developed objective criteria that effectively
>> removed the 'malicious curve' issue.

Exactly.

> Curves are a different matter... I doubt that it really matters very much and
> the differences in speed are likely to turn out to depend on whose hardware is
> used. 
> 
> Easiest to explain is probably the best criteria.
 
Probably so.