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

"Blumenthal, Uri - 0558 - MITLL" <> Thu, 29 January 2015 21:39 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 72A8A1A87CD for <>; Thu, 29 Jan 2015 13:39:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.308
X-Spam-Status: No, score=-2.308 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QhsWb2WB7IzY for <>; Thu, 29 Jan 2015 13:39:24 -0800 (PST)
Received: from (MX1.LL.MIT.EDU []) by (Postfix) with ESMTP id 1476C1A87D4 for <>; Thu, 29 Jan 2015 13:39:23 -0800 (PST)
Received: from ( by (unknown) with ESMTP id t0TLd3dJ032119; Thu, 29 Jan 2015 16:39:20 -0500
From: "Blumenthal, Uri - 0558 - MITLL" <>
To: Phillip Hallam-Baker <>
Thread-Topic: [Cfrg] big-endian short-Weierstrass please
Thread-Index: AdA6QfeHnVWfJGNlTzek7rmrn4E15gBEvvUAAAkmA5D///TDAIAACxgA//+0JACAAW5uAP//wsgngABbjQD//8TFAAALA4SAAAG2iwAACSj+gA==
Date: Thu, 29 Jan 2015 21:28:57 +0000
Message-ID: <>
References: <> <> <> <> <20150128231006.GJ3110@localhost> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha256"; boundary="B_3505393731_1192590"
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_07: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-1501290205
Archived-At: <>
Cc: "" <>
Subject: Re: [Cfrg] big-endian short-Weierstrass please
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 29 Jan 2015 21:39:27 -0000

>> That seems irrelevant. Some people will never be convinced of some things
>> that most other people agree to.
> What is being argued against here is making room for DIY curves.
> My point is that the only way to come up with an informed decision to use
> someone else's curves is to apply a vast amount of domain specific expertise
> plus really trust the supplier to not have something up their sleeves.

Unless that “somebody else” is your boss, or somebody you have informed
reasons to trust.

Some people (and organizations :) tend to trust “their” experts, and not
trust “other” experts as much. As an example – why didn’t NSA adopt Russian
GOST, and why didn’t Russians adopt AES? Probably not because they question
the competence of the other side? :-)

I’m arguing that there is a need for DIY curves, on both personal and
“organizational” level.

> So I think we can come up with a decision here but the process makes me
> certain that there is no possibility that two random computers could negotiate
> a secure set of curves on the Internet via a protocol. Unless that is we
> assume some form of out-of-band trust relationship.

There should be a set of “universally” accepted curves, so that when you
want to talk to a complete stranger – both of you would use what the
“community” considers cryptographically OK (which belongs to that small
commonly shared set). But that’s only half of use cases.

There should be an option to specify “my own” curves, so that when, e.g. one
“team" member wants to talk to his peer – their software will pick that
special curve that was for whatever reasons approved by their boss, or
refuse to connect. Because in that context ability to establish a connection
with a stranger is underisable.

> My view is that we should pick Curve 25519 because it is a decent balance of
> expediency and security for the performance curve and P512 because it removes
> virtually all possibility of 'up their sleevesies' argument for the highest
> assurance curve…..
> That said, I prefer the Edwards curves because I can explain them to other
> folk without resorting to abstract math (now I have been given the link to
> DJB's presentation at Chaos). The use of The Wierstrass forms are much less
> friendly.

I see your point.