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

Alyssa Rowan <> Thu, 29 January 2015 07:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 713B21A8AFA for <>; Wed, 28 Jan 2015 23:13:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.502
X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BXpVTtGJZsA0 for <>; Wed, 28 Jan 2015 23:13:18 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0F0F81A000C for <>; Wed, 28 Jan 2015 23:13:18 -0800 (PST)
Message-ID: <>
Date: Thu, 29 Jan 2015 07:13:18 +0000
From: Alyssa Rowan <>
MIME-Version: 1.0
To: "" <>
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <>
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 07:13:22 -0000

Hash: SHA512

On 29/01/2015 00:37, Phillip Hallam-Baker wrote:

> Right. The objective here is to dump all the existing code in the 
> trash and start again. Because we want the implementations to have 
> constant time implementations and to preclude the possibility of 
> malicious point attacks by choosing curves that allow us to easily 
> compute y from an x, and only sending the x.
> What we want to avoid at all costs is patent encumbrances. Dumping 
> Weierstrass is a pretty good start because that was the favorite 
> curve of the folk who applied for most of the patents.

+1 to all of this.

> The only area where I did have concerns is that to be able to 
> deploy crypto on these platforms I have to be able to buy FIPS 
> certified hardware or equivalent.

It's probably going to have to be "equivalent", unless NIST surprise us
and come to like the curves and algorithms we do.

> Before the new curves can be used in browsers for certs, the 
> browser providers are going to have to be satisfied.

…and we're going to need a signature algorithm. Our draft doesn't have
one of those, and it seems what we're planning to do is do that in a
second phase, as you address.

> … But I don't want to do that in a way that makes it difficult to 
> move to EC certificates in the future.


> I don't accept that big endian is more error prone. The existing 
> code for X.509v3 crypto is all big endian. Changing that will 
> introduce a new code path and opportunity for error.

Two points here.

1. There's a special circle of hell reserved for those who maintain
   X.509v3 code, where they debug ASN.1 parsers for all eternity! <g>

   Seriously though, if I want to dump some TLS code in the bin and
   rewrite it because it's too hairy, X.509 would be the first thing on
   the list.

2. I think that may well be an engineering decision, for the TLS WG or
   PKIX WG. What we've got here is the wire format of the raw function,
   and I continue to think that's the best approach to keep.

   TLS WG already discussed this and used that directly - little-endian
   and everything - for their Curve25519 key-exchange draft. I see no
   reason to second-guess that. They then also specified new curve
   point formats should be opaque octet strings to them, with no
   special treatment. Doesn't sound like they think endian-swapping for
   transport wire formats is worth it from an engineering perspective.

   It'd probably have to be PKIX WG who figure out how to put the wire
   format of whatever signature algorithm we - later - specify into
   whatever format they specify. If they want LE, or BE, or BCD, or
   ASCII base-10, or wrap it in ASN.1 with an OID and a ribbon on top,
   isn't that properly for them to decide? Either way, I don't think
   that's a big deal: if they really want to endian-swap, they can, but
   I'm not sure we should pre-empt them here.

> Now it should be quite easy to add the new curves to the list. I 
> suspect that unless the browser providers are feeling really 
> generous, they will expect us to end of life our existing ECC
> certs to get the new ones added.

I can't speak for them of course, but that's not the impression I get
from either them or CAs? We aren't _replacing_ NIST curves as far as I
know in a near-term timescale, but providing a better alternative for
the future. NIST seem to have much less sway with NGOs than previously.

There will probably be a steady transition to using them, but, say,
those who need FIPS (as above) may never be able to, unless NIST
shadow our recommendations - which would honestly surprise me, but who

- --