[Cfrg] Safecurves draft redux

Watson Ladd <watsonbladd@gmail.com> Thu, 09 January 2014 14:42 UTC

Return-Path: <watsonbladd@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 455631AE30F for <cfrg@ietfa.amsl.com>; Thu, 9 Jan 2014 06:42:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y_xvrswKmdu2 for <cfrg@ietfa.amsl.com>; Thu, 9 Jan 2014 06:42:36 -0800 (PST)
Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id B67611AE338 for <cfrg@irtf.org>; Thu, 9 Jan 2014 06:42:35 -0800 (PST)
Received: by mail-wg0-f43.google.com with SMTP id k14so2864875wgh.10 for <cfrg@irtf.org>; Thu, 09 Jan 2014 06:42:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=O2onGku8zDqnsMWME+PTMSqtWF+I7Wu9xlTSHNQgvK8=; b=bDCQJKFeMmMpQFjrKUhLmmsubf9XqbSGW9WAMh0F7Gu6dc0Iem974OEsbmSQu28Cb1 dSt1YEQGAwgjIWufMEji0EqdxBWPjB8tTBQkSHG4ikzWdXmjch6QxUReEay39kXDT91s axGNj4vlu6Oc+BzQU+00GVG3wFGVgqQdz0Bh/sgg2IYtoQQfTfH0iQaKqF+aaNGgdjf9 ipWhNEsKtnyOU9P0aPiKZzOso5cYua5z3Y6N6gXMLc8iSVSAEuQA9/f+GQB0VnkfSnIr ReLE/LHRCEF0GFwipL35NkQCRRyZIjVCFZIwSDaDB86Y5I8ucAwmqVID3U9gWYy7yi+s DGCQ==
MIME-Version: 1.0
X-Received: by 10.180.86.9 with SMTP id l9mr3690152wiz.20.1389278545092; Thu, 09 Jan 2014 06:42:25 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Thu, 9 Jan 2014 06:42:25 -0800 (PST)
Date: Thu, 9 Jan 2014 06:42:25 -0800
Message-ID: <CACsn0cn4paZTmeVExn+na0MwzdvSn+MF_bmyRZ869pJrWb_8Bg@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: "cfrg@irtf.org" <cfrg@irtf.org>
Content-Type: text/plain; charset=UTF-8
Subject: [Cfrg] Safecurves draft redux
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: Thu, 09 Jan 2014 14:42:37 -0000

Dear all,
The email thread about the draft exploded and I had a lot of points to
respond to all over the place.

First off, I am including explicit formulas in the draft. It costs
nothing, and people seem to want it. I'm also explaining the benefits
of Montgomery form for x-coordinate only ECDH. I'll upload it as soon
as I'm happy with some editing I need to do.

The naming issue is fine: we can say "the safecurve Mxxx has been
found to be unsafe" without risk of being misunderstood. If there is
consensus that we should call the IANA registry something else, say
"Chicago curves", I'm not opposed to it.

But as for efficiency, pontification about what is fast and what isn't
will always be behind the drive of implementors to accelerate
everything. What seems like an awkward limb placement can be fixed by
some clever use of fractional radix arithmetic.

Lastly, just because a protocol suggests a form to go on the wire does
not mean that the calculations an implementation does need to resemble
it. Robert Ransom has made this point, and I agree with it. Good
standards specify observed behavior, not how it is attained.

As a metacomment: we shouldn't let our desire for "The Idiots Guide to
ECC" in RFC form get in the way of standardizing these curves. I don't
think our job is done with putting these curve formulas in an RFC, but
it does substantially help anyone who wants to use these curves in
another IETF protocol.

Sincerely,
Watson Ladd