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

Nico Williams <> Thu, 29 January 2015 18:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0DDFF1A19F0 for <>; Thu, 29 Jan 2015 10:13:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 23j-OTnmUWhH for <>; Thu, 29 Jan 2015 10:13:46 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D21951A1A5A for <>; Thu, 29 Jan 2015 10:13:45 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id 610BF2004EE9F; Thu, 29 Jan 2015 10:13:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to;; bh=oLlZRbPkXW14wt zIsYBKdUOoVhM=; b=OUA0/tN0K/AQGF3117G8jd4WRPUUMHybjEO5mYU71vfVRh Aq5zAPM/2lkeKkBxu62LnOnm0qJ5zQ/pn//X1pvd9nKp/pZd0ecYExQW3TLUFotR LjNMtmLWQLKIH9XRf2wH+g6uvffEifHL2Zva9HdXH18FBi0vYXeNb7lJ146cw=
Received: from localhost ( []) (Authenticated sender: by (Postfix) with ESMTPA id 0A64F2004EE8D; Thu, 29 Jan 2015 10:13:44 -0800 (PST)
Date: Thu, 29 Jan 2015 12:13:44 -0600
From: Nico Williams <>
To: Dan Brown <>
Message-ID: <20150129181339.GT3110@localhost>
References: <> <> <> <> <20150128231006.GJ3110@localhost> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
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 18:13:47 -0000

On Thu, Jan 29, 2015 at 05:58:03PM +0000, Dan Brown wrote:
> >From: Watson Ladd []
> >This is not how TLS negotiation works: the client offers and the server 
> >picks. Due to vulnerabilities in all versions of TLS (still unfixed) one 
> >always has to check the offered parameters for correctness.
> [DB] Ah, too bad. I guess named curves (and FFDHE groups) is, among other 
> things, one way to fix this problem with TLS.  (I vaguely recalled a proposal 
> for the server being able to suggest alternatives outside the clients' list, I 
> guess I misremembered.)
> Anyway, to paraphrase others, a downside of TLS limiting curves to a small 
> set, is this limitation can be spun sourly, albeit a tad unfairly, as 
> pressuring users to use particular curves. That said, leaving in arbitrary 
> curves, can also be spun badly, too, catch 22.

We can haz both even, though I don't see the value in it; known curves
FTW.  The key is to have a relatively open curve registry (open -> less
than IESG Protocol Action should be needed to register, probably Expert

The same is true for traditional DH.  We've had known groups for a long
time.  Some protocols (e.g., SSHv2) allow negotiation of arbitrary
groups, but a) it takes a long time to generate them, b) it takes longer
to validate (then use) them than it would to just use an off-the-shelf
group.  I would say that arbitrary group negotiation is a failure in all

> >That's on top of the fact that people don't want to use Curve25519 because 
> >it's Curve25519. They want to use it because the design choices support high 
> >speed secure implementations.
> [DB] Right, but other users might want to use some other curves with high 
> speed secure implementations, e.g., maybe a larger curve, but they disagree 
> with CFRG advice about rigidity, etc.

See point above about a curve registry.  For protocols like SSHv2 where
there's a large private-use namespace for curve names, a registry is not
even required, and the Internet can come to consensus by market

A generic point format for all curves to use is simply not something we
need for anyone's favorite curves (or curve families) to be deployable.