[Cfrg] new curves vs. algorithms

Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 17 January 2014 12:57 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id D3F4C1AE0A9 for <cfrg@ietfa.amsl.com>; Fri, 17 Jan 2014 04:57:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.438
X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id yTtZws8ztf8v for <cfrg@ietfa.amsl.com>; Fri, 17 Jan 2014 04:57:18 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie []) by ietfa.amsl.com (Postfix) with ESMTP id DE6B41AE0A6 for <Cfrg@irtf.org>; Fri, 17 Jan 2014 04:57:17 -0800 (PST)
Received: from localhost (localhost []) by mercury.scss.tcd.ie (Postfix) with ESMTP id DB41DBE2F for <Cfrg@irtf.org>; Fri, 17 Jan 2014 12:57:04 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([]) by localhost (mercury.scss.tcd.ie []) (amavisd-new, port 10024) with ESMTP id bphximN8Rhu1 for <Cfrg@irtf.org>; Fri, 17 Jan 2014 12:57:04 +0000 (GMT)
Received: from [] (stephen-think.dsg.cs.tcd.ie []) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8CE66BE25 for <Cfrg@irtf.org>; Fri, 17 Jan 2014 12:57:04 +0000 (GMT)
Message-ID: <52D928A1.6070201@cs.tcd.ie>
Date: Fri, 17 Jan 2014 12:57:05 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Cfrg@irtf.org
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [Cfrg] new curves vs. algorithms
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jan 2014 12:57:20 -0000


I've a question that I think might be worth looking
at when the "new curves" work has settled down a
bit more. (Since I'll forget about it:-) I'm gonna ask
now, but I hope this doesn't get debated until later.

Given that the implementations of the nist curves and
these new curves are radically different and perhaps
quite likely to be done by different folks, 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'm not sure what answer I prefer, nor if it makes
that much difference, but we should ponder it before
we eventually get to allocating OIDs or other protocol
codepoints. A lot of that is protocol specific but
some is likely generic and might be considered by cfrg.
(When I say "considered" I mean I think it could be
useful if cfrg have given some thought as to how to
get these new curves used. That could be just mail
list traffic though, and need not be text in an RFC.)

I hope the criteria to be used when considering this
(if its significant) would be to go with whatever will
make implementation and deployment easier, since the
impact might be more on APIs and libraries rather than
on protocols, but doing the wrong thing might make it
harder to get broad support for the new stuff, e.g.
if some v. popular implementations had APIs that made
it hard to do both nist and "new" curves depending
on whether the new ones are viewed as a different
algorithm or alg-param.

Or maybe its a dumb question, in which case sorry
for wasting the bytes:-)