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

Phillip Hallam-Baker <> Thu, 29 January 2015 20:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D59971A1AFF for <>; Thu, 29 Jan 2015 12:51:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id M6I6-haP_ae7 for <>; Thu, 29 Jan 2015 12:51:11 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 68F7B1A1A59 for <>; Thu, 29 Jan 2015 12:51:10 -0800 (PST)
Received: by with SMTP id b6so32493954lbj.11 for <>; Thu, 29 Jan 2015 12:51:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=gGm+ck3MhftezE0tWGbLFqJoNWoLWUJNrDBQBwfPt18=; b=G7CIq7TQqo8piUbOjAkxzJIhGGDiKnEgbKQYGQVEGs8jF72F2acYIjs88uX+7d5AJ8 0HcyXq1EtKxKxqclHRCJUvu1ToOdUu2RX0BzSiEVxLd8L28KHxuzksFV9NsDvBecjSbX 98RuSq5+Kd7Do/ryGITUKn0+puPmCsxs3KWYmu0Df5NrYxK0ieey+2Wh12Hzrl4tv2ic phDVGdg3vKHSiZzXulvPrghiMYuSneag+blP4ujG6Egv4r2D+CjUkhsSKMVGCfEy9TZJ Zgu/S8Q9pHq531J5fzQ/bitLvvYpX7tfydQqed9RZOk7Lf3xVxKFSBmQHkqTXdOadL4t WdSg==
MIME-Version: 1.0
X-Received: by with SMTP id z5mr3184576laz.19.1422564668736; Thu, 29 Jan 2015 12:51:08 -0800 (PST)
Received: by with HTTP; Thu, 29 Jan 2015 12:51:08 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <20150128231006.GJ3110@localhost> <> <> <> <> <> <> <>
Date: Thu, 29 Jan 2015 15:51:08 -0500
X-Google-Sender-Auth: yxpApA8r97Px3DZMcoDhMk7xyiw
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Paul Hoffman <>
Content-Type: multipart/alternative; boundary="089e01494332c00d69050dd0a5a5"
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 20:51:13 -0000

On Thu, Jan 29, 2015 at 3:02 PM, Paul Hoffman <> wrote:

> > On Jan 29, 2015, at 11:46 AM, Blumenthal, Uri - 0558 - MITLL <
>> wrote:
> >
> >> On Thu, Jan 29, 2015 at 12:50 PM, Watson Ladd <>
> 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?
> No. Are you saying that you will only use curves that NIST says are
> secure? Or that somehow CFRG has to convince NIST?
> > How would you convince others that BRAINPOOL might have had something up
> their collective sleeve, but you don’t?
> 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

We are working on a scheme to reduce the amount of scope of 'up our
sleeves' to the absolute minimum or close to it and getting what is surely
the best available expertise from the field to comment.

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.

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.

While it is true that there are multiple forms in which the curves might be
expressed, these issues are really very much less of a concern because
first, all the curves we are discussing are isomorphic.

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