IETF Logo Mail Archive

Re: [Cfrg] Submission of curve25519 to NIST from CFRG -> was RE: On "non-NIST"

Paul Lambert <paul@marvell.com> Tue, 10 March 2015 22:34 UTC

Return-Path: <paul@marvell.com>
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 DDDD81A8F3C for <cfrg@ietfa.amsl.com>; Tue, 10 Mar 2015 15:34:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level:
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 Th9CrGq0WQ_j for <cfrg@ietfa.amsl.com>; Tue, 10 Mar 2015 15:34:48 -0700 (PDT)
Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F6151A8F46 for <cfrg@irtf.org>; Tue, 10 Mar 2015 15:34:48 -0700 (PDT)
Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id t2AMTEpT031746; Tue, 10 Mar 2015 15:34:47 -0700
Received: from sc-owa.marvell.com ([199.233.58.135]) by mx0a-0016f401.pphosted.com with ESMTP id 1t1e6j546q-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 10 Mar 2015 15:34:47 -0700
Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA.marvell.com ([::1]) with mapi; Tue, 10 Mar 2015 15:34:46 -0700
From: Paul Lambert <paul@marvell.com>
To: Watson Ladd <watsonbladd@gmail.com>
Date: Tue, 10 Mar 2015 15:34:45 -0700
Thread-Topic: [Cfrg] Submission of curve25519 to NIST from CFRG -> was RE: On "non-NIST"
Thread-Index: AdBbgJipiwkYWccoRMaqI5PD4O5SPAAANSfg
Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D020E29C4340@SC-VEXCH2.marvell.com>
References: <9A043F3CF02CD34C8E74AC1594475C73AAF91123@uxcn10-5.UoA.auckland.ac.nz> <BE305B0B-80D2-48C6-ACE6-6F6544A04D69@vpnc.org> <7BAC95F5A7E67643AAFB2C31BEE662D020E29C4319@SC-VEXCH2.marvell.com> <CAHOTMVLJOhsPoUDoh176U5iM7cOhm_wvCWAY+L8V4m99O4u9TA@mail.gmail.com> <CACsn0ckg2e9wXTuiZD+CaOreKcK+GNrXAWQ1=SyGG9sa=dsJRg@mail.gmail.com>
In-Reply-To: <CACsn0ckg2e9wXTuiZD+CaOreKcK+GNrXAWQ1=SyGG9sa=dsJRg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_7BAC95F5A7E67643AAFB2C31BEE662D020E29C4340SCVEXCH2marve_"
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-03-10_08:2015-03-10,2015-03-10,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound 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-1503100230
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/mxHUTqGLCMN0S75WlseXTTktZ9U>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>, "EllipticCurves@nist.gov" <EllipticCurves@nist.gov>
Subject: Re: [Cfrg] Submission of curve25519 to NIST from CFRG -> was RE: On "non-NIST"
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: Tue, 10 Mar 2015 22:34:50 -0000

> Standards fragmentation is a fact of life. But we should strive to minimize it.
>And we shouldn't make it worse by varying endianess or encoding for
Could we please desist with the off-topic rants.  This was a request to the Chairs
to work more directly with NIST to propagate this task groups recommendations.
There was NO mention of endian! Such irrelevant points only add noise to
the mailing list.
>something that for 8 years was done a different way: there's no
>benefit to doing it needlessly.
Duh … and what about the 15+ years everyone else has setup the
bytes the other way round… (please do not answer on list, I don’t
care about the byte order today, my point is on irrelevant noise
and arguments).  If you wish to debate endian … start your
own new subject line.

Paul


From: Watson Ladd [mailto:watsonbladd@gmail.com]
Sent: Tuesday, March 10, 2015 3:22 PM
To: Tony Arcieri
Cc: EllipticCurves@nist.gov; Paul Lambert; cfrg@irtf.org
Subject: Re: [Cfrg] Submission of curve25519 to NIST from CFRG -> was RE: On "non-NIST"


On Mar 10, 2015 3:17 PM, "Tony Arcieri" <bascule@gmail.com<mailto:bascule@gmail.com>> wrote:
>
> I am very curious about this as well. It would make for a very confusing situation if NIST adopted different curves from the CFRG curves.
>

and Brainpool, and the French and Chinese governments, and the Russians, and the Brazilians.

Standards fragmentation is a fact of life. But we should strive to minimize it. And we shouldn't make it worse by varying endianess or encoding for something that for 8 years was done a different way: there's no benefit to doing it needlessly.

> --
> Tony Arcieri
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org<mailto:Cfrg@irtf.org>
> http://www.irtf.org/mailman/listinfo/cfrg
>

v2.23.0 | Report a Bug | By Email