Re: [Cfrg] generic curves ... RE: big-endian short-Weierstrass please

Phillip Hallam-Baker <> Tue, 03 February 2015 19:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id F14AB1A8751 for <>; Tue, 3 Feb 2015 11:03:30 -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 C9lEmP5e8MnX for <>; Tue, 3 Feb 2015 11:03:29 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 899851A066C for <>; Tue, 3 Feb 2015 11:03:28 -0800 (PST)
Received: by with SMTP id s18so54205785lam.3 for <>; Tue, 03 Feb 2015 11:03:26 -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=R8E7satdK6eXsRN2XmwtoANpKGCZ0eYeS5sFF3stLhI=; b=JsboXBcsbFNnEgk72qAyEs65IIPECbrHqI++B+Whz9R+f3NIElEFcR8WN28oAtfR6E JYtrkWFTik2VipceE/jDabqxvMwqusY8qt5yuo/416jDSisYU2n2ASDhVkHGiwTC/atK t5AS32dM8Bl2ZQfeBXwYo+rr8z7ml760vBNv1QQlU1gENnJJChyZSFU1ZlycO8QsutNY 0vfquJQgCWjsqUL0g0+7bgnziRAZxtCZBd27BfnfZ1aLAa0dR4N+DIYtpOyoFDzef1yf LSPSlD8cDvIuHrEppzF10v5j1hzMV5gTEXWa6bcrRCN+P3cUaPm47BSZthjsLuFvwsVC BlAg==
MIME-Version: 1.0
X-Received: by with SMTP id ji5mr26499511lbc.45.1422990206575; Tue, 03 Feb 2015 11:03:26 -0800 (PST)
Received: by with HTTP; Tue, 3 Feb 2015 11:03:26 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
Date: Tue, 03 Feb 2015 14:03:26 -0500
X-Google-Sender-Auth: kHKK0HIsXjFN0ts0a5OdSyT-CoY
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Watson Ladd <>
Content-Type: multipart/alternative; boundary="001a11c23908c82b73050e33b932"
Archived-At: <>
Cc: Dan Brown <>, "" <>
Subject: Re: [Cfrg] generic curves ... RE: 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: Tue, 03 Feb 2015 19:03:31 -0000

On Tue, Feb 3, 2015 at 11:50 AM, Watson Ladd <> wrote:

> On Mon, Feb 2, 2015 at 2:29 PM, Kurt Roeckx <> wrote:
> > On Thu, Jan 29, 2015 at 10:09:18PM +0000, Dan Brown wrote:
> >> New thread name ... should have done so earlier.
> >>
> >> When TLS asked CFRG for new curves, I didn't interpret that to mean that
> >> generic curves would be banned. Banishing generic curves adds slightly
> more
> >> weight to the TLS request, because users cannot easily opt out of the
> chosen
> >> few elite curves.
> >
> > If it's unclear what the TLS WG wants exactly, maybe it's best to
> > ask them?
> >
> > My understanding is that they want fixed named curves.
> Let me get this right:
> There are no security concerns with Curve25519.
> For the entire 12 months we've been piddling away, we could have
> written Curve25519 in Weierstrass form, and the TLS specification
> would already have included it as an option.

No I don't think that is correct. The arguments for Curve25519 are

1) Performance
2) There is not enough difference between 255 and 256 to be worth arguing
3) Legacy implementation
4) Avoidance of patent issues.

Weierstrass form would not address the last two.

If I end up having to get up in court as an expert witness, it is a lot
easier for me to show someone that the Edwards version of a curve does not
infringe some Weierstrass related twiddle than it is for the competing
expert to convince a jury that Weierstrass and Edwards forms are isomorphic.

Seriously guys, how many folk do you think we have in the community who can
explain this stuff to a jury and how many of those would you want to put
anywhere near a jury hearing a case you had an interest in?

> We've still got signatures and the choice of primes at higher security
> levels to worry about, with about 10 emails total on these topics.

I must have written 20+ on the higher security curve:

* I don't think there are going to be fully objective criteria.

* I really don't want to go over 512 bits because it breaks stride. I
already have hardware with 512 bit data paths. I do not expect to have
hardware with a 1024 bit path and if I did I would want to make full use of

* I don't care about a performance difference unless it is at least a
factor of two.

* 512 bits is a really nice round number.

Instead we've spent 90+ emails debating whether an opaque byte vector
> should be big or little endian, after the TLS WG already had this
> debate.

And I don't think it is even in scope for CFRG. TLS handles ephemeral keys
and PKIX keys in different ways. There is no requirement for both to be
handled the same way.

It is very clear that the PKIX representation has to be big endian because
the ASN.1 code that maps RSA keyinfo data to internal math structures is
going to be the same code folk want to use for ECC.

So basically TLS has to choose between having the ephemeral ECC structures
be consistent with the legacy Curve25519 implementations or be consistent
with the PKIX Keyinfo specification. End of story.

> We've exceeded a previously announced deadline by a month. We're still
> picking editors for a draft that has a hard deadline coming up in
> March (several hard deadlines), despite dropping several deliverables
> to make it, and knowing that X25519 is going to be what is in the
> eventual RFC.

Was this a surprise to you?

I remember attending one of the SDMI conferences where the speakers on the
podium assured us that there would be a spec by Xmas because there must be
one by then. They were still at it two years later.