Re: [Cfrg] new curves vs. algorithms

Alyssa Rowan <> Fri, 17 January 2014 20:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4A9471AE1DD for <>; Fri, 17 Jan 2014 12:00:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_75=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W6D_h7MqLvPU for <>; Fri, 17 Jan 2014 12:00:16 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 3947E1AE191 for <>; Fri, 17 Jan 2014 12:00:14 -0800 (PST)
Received: from [] ( []) by (Postfix) with ESMTPSA id F144D6031B for <>; Fri, 17 Jan 2014 20:00:00 +0000 (GMT)
Message-ID: <>
Date: Fri, 17 Jan 2014 20:00:07 +0000
From: Alyssa Rowan <>
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [Cfrg] new curves vs. algorithms
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: Fri, 17 Jan 2014 20:00:18 -0000

Hash: SHA512

On 17/01/2014 12:57, Stephen Farrell wrote:

> […] is there a benefit in treating these as if they were entirely
> different algorithms in terms of codepoints in protocols, or are we
> better off just regarding them as different curves for the same
> algorithm.

I think that's _very_ protocol-specific, even feeding from what
implementers and existing libraries find most amenable to updates.

I think the only really important thing is that everyone's
crystal-clear about what is what, exactly. (Same as with naming, really?)

Example: For TLS, ECDHE with Montgomery curves (notably curve25519) is
pretty straightforward! draft-joseffsson-tls-curve25519-03
specifically proposes to use the existing ECDHE ciphersuites with
NamedCurve curve25519 (and probably so on for each of the suitable
"Chicago curves" supported); and an implicit opaque ECpoint.point
(currently being debated as to endianness and length).

That seems a sensible approach to me: less code rewrite, less messing
about with library internals, and hopefully the ability to incorporate
the existing great routines out there already to accelerate actual
deployment for something considered an urgent requirement (efficient
forward security).

But conversely, please _don't_ try to just use ECDSA with these
curves. I think that'd be a bit of a square peg in a round hole: you
might be able to make it fit if you really hammered it, but you risk
cutting corners if you did! <g>

There's a discussion in progress around a potential Schnorr-style
signature scheme suitable for use with Edwards (and/or Twisted
Edwards) curves instead and which wouldn't eat entropy when signing -
probably based heavily on djb/Lange's Ed25519 paper, but a bit more
generalised/updated/cleaned-up to fit the other curves we document?
(We're still in the early planning phase.)

I'd think an entirely different signature algorithm like that _would_
warrant a different algorithm ID - but of course that's a future
something for WGs at such a time there's got a solid proposal for it.

- --