[Cfrg] Fwd: Re: Safecurves draft

Alyssa Rowan <akr@akr.io> Thu, 09 January 2014 08:12 UTC

Return-Path: <akr@akr.io>
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 859AB1AE1C9 for <cfrg@ietfa.amsl.com>; Thu, 9 Jan 2014 00:12:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id nOYwWZkkofZb for <cfrg@ietfa.amsl.com>; Thu, 9 Jan 2014 00:12:33 -0800 (PST)
Received: from entima.net (entima.net []) by ietfa.amsl.com (Postfix) with ESMTP id 9A32A1AE06F for <cfrg@irtf.org>; Thu, 9 Jan 2014 00:12:33 -0800 (PST)
Received: from [] (cpc5-derb12-2-0-cust796.8-3.cable.virginm.net []) by entima.net (Postfix) with ESMTPSA id BD5876041A for <cfrg@irtf.org>; Thu, 9 Jan 2014 08:12:23 +0000 (GMT)
Message-ID: <52CE59F4.8050205@akr.io>
Date: Thu, 09 Jan 2014 08:12:36 +0000
From: Alyssa Rowan <akr@akr.io>
MIME-Version: 1.0
To: cfrg@irtf.org
References: <52CE59C1.6020500@akr.io>
In-Reply-To: <52CE59C1.6020500@akr.io>
X-Forwarded-Message-Id: <52CE59C1.6020500@akr.io>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: [Cfrg] Fwd: Re: Safecurves draft
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 08:12:36 -0000

Hash: SHA512

On 08/01/2014 23:50, Watson Ladd wrote:

> I don't want to rename curves because that induces consistency 
> issues.

Entirely accepted: I raised it merely as a question. People are
already beginning to adopt these curves of their own volition, so
changing the names of them could be confusing, yes.

As other have raised, putting the ladders in the appendix would
definitely be a good idea, and we need to explain the criteria under
which they were designed, which is what makes them so useful.

And yes, we should definitely get some OIDs. (However you actually
_do_ that. I've no idea.)

On 09/01/2014 01:32, Paul Lambert wrote:

> Comment: -too terse

It's an early draft. There's some fleshing-out still to go.

> - no clear mapping of numbers to variables - no documentation of 
> Edwards point addition Which is different from durrent ECC drafts

See above. Agreed.

> - no indication of security concerns and need or lack of checking 
> public key values

Important advantages. We should cover this, I think.

> Here¹s how I¹d document curve parameters: […python…]

> PS - above parameters are directly executable Python code Why use 
> pseudo code when you can use real code :-)

Advantage: People can copy-and-paste it into their implementations.
Disadvantage: People will copy-and-paste it into their implementations.

I honestly don't know which practice is preferable.

Naïve Python implementations directly using the bignums rather than
the good addition ladders probably wouldn't be constant-time - would they?

On 09/01/2014 03:11, Dan Brown wrote:

> I don't object to these curves.


> […several objections to the name ‘safe’, implying other curves 
> aren’t, raising the NIST curves…]

As the SafeCurves criteria clearly explains:

• Their design criteria are transparent, and rigid, with few
  opportunities for an attacker to secretly select cryptanalytically-
  useful choices¹.

• They support simple, fast, complete, constant-time single-coordinate
  single-scalar and multi-scalar multiplication techniques which work
  in every case.

• These can be implemented using relatively-simple (compared to short
  Weierstrass) ladders which are both constant-time, and extremely

• They have large complex-multiplication field discriminants; are safe
  against additive and multiplicative transfer; and have secure twists.

Compared to the curves we've got at the moment (most of which don't
even have clearly-explained design criteria, and the ones that do are
unfortunately inefficient), the choice of name seems entirely apt to me.

Besides, it's what they're already widely known and referenced as:
people are already in the process of implementing these. As above,
changing it probably wouldn't be helpful and would just confuse people.

1. Contrast, say, the NIST/SEC curves generated by Certicom, whose
   design criteria are what I can only describe as “opaque” —
   mysterious black-box values which SHA-1 hash out to “provably
   random” parameters, but which are not in fact random themselves:
   the design team minted those values via repeated iteration to
   deliberately and secretly ensure they would meet some set of
   criteria (and then even listed the prime order in decimal to
   disguise the structure).

  (Sources are under the impression that was actually a set of
   criteria to ensure the curves would be efficiently implemented via
   Certicom-patented methods, but unfortunately, cannot state for sure
   that the criteria didn't also include cryptanalytically-useful
   weaknesses, and of course, that's what people are worried about,
   given the news. They didn't actually _see_ any attempt to actually
   weaken the NIST curves, they can at least say that much — phew —
   but that's little help in positively assuring it didn't happen.)

   These have no such concern.

- --