Re: [Cfrg] Safecurves draft

Watson Ladd <> Thu, 09 January 2014 00:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 44B751ADEA0 for <>; Wed, 8 Jan 2014 16:58:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 51dMo_tMRB01 for <>; Wed, 8 Jan 2014 16:58:34 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c05::236]) by (Postfix) with ESMTP id 987A61AD9AB for <>; Wed, 8 Jan 2014 16:58:34 -0800 (PST)
Received: by with SMTP id en1so2844579wid.9 for <>; Wed, 08 Jan 2014 16:58:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=E3b9yuMe+H/JiwtjEztpkBWrLhiy8pgqsfnk4Qmrlbg=; b=NY7uSANdYru+MYDTBKYSzV+yD58Oes64u7FX1Ww9EeiZ4atgfzrN2r7VQxkW8OLt5v 5qLhj03XaDaqxwsb3g7lpHHVXq47lrnlJ89iaUC56a9a0J7h0LIxRXZDNk6sOwEgyG7J 2bHhBpf/oKVTQttuMEij7kvMrl9hJrn3CDZxa1xTy6eG7eohxiW97SYK+4esBGB2GPv/ blMDUjDe4ZP23AqrhmpgPMRQ1hXINWDoFnZZT8PPwxJP1jZBfQ1in9bEEyztOY+vQp/V 0zDLYtCRcSorUTCkwIHoXw/+s7ae1RJcAMeqjMatfpoP0sf3pNUqSyRJX3Qndd39JiGi Pdcw==
MIME-Version: 1.0
X-Received: by with SMTP id fr5mr178532wjc.76.1389229104743; Wed, 08 Jan 2014 16:58:24 -0800 (PST)
Received: by with HTTP; Wed, 8 Jan 2014 16:58:24 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Wed, 08 Jan 2014 16:58:24 -0800
Message-ID: <>
From: Watson Ladd <>
To: Paul Lambert <>
Content-Type: text/plain; charset="UTF-8"
Cc: "" <>
Subject: Re: [Cfrg] Safecurves draft
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, 09 Jan 2014 00:58:36 -0000

On Wed, Jan 8, 2014 at 4:30 PM, Paul Lambert <> wrote:
>> > You should also look at: RFC 6090
>> > The math for Small Wierstrass curves is defined well - you need the
>> > equivalent of
>> > 6090 for Edwards curves.  Do note the authors of this excellent RFC
>> > Include both chairs of this list.
>> First, is this advising me on next steps, or is it an objection to the
>> draft?
> Next steps.  I'm very supportive of the inclusion of these curves into the main stream.
>> The group is [l]Jac(E(F_q)). There, done. In fact, this is in the
>> introduction.
>> The equivalent to RFC 6090 is the Bernstein paper on addition on
>> Edwards (and twisted Edwards curves).
>> It's readily available. If you want to reformat it as an I-D, go right
>> ahead.
> Academic papers are not appropriate directly.  Clear and concise algorithm
> descriptions and guidelines are required.

But the explicit formulas aren't actually required for intereop. I'll
put them as informational because it took me a few minutes to
write them down in the draft, and I don't mind that much.
 We don't define how TCP clients should maintain the buffer of sent
information efficiently, or how
routers should maintain the routing tables. OSPF doesn't explain how
to maintain a binomial heap.
This sort of information might belong in an RFC. But its lack doesn't
make a standard insufficient.

Anyway, this is totally immaterial: the next version, which fixes some
typos, adds E-521, and removes a badly designed
curve (secure but slow), adds in a section explaining the formulas
will hit the RFC editor some time next week: I want to collect
more comments and resolve them.

Take a good look for typos: that's what can really mess this whole thing up.

Anyway, once I get the next version up, I think we'll pretty much be
ready on this, assuming no major dealbreakers appear.

>> Is it really that bad to have the EFD get cited for the formulas, or to
>> advise implementers to read Handbook of Elliptic and Hyperelliptic
>> Curve Cryptography?
> Yes.  They are not standards.  They are not always precise and subject to
> Interpretation and bad implementation.
> They are not complete ... Dan's point about OIDs and the like required
> to actually use the curves.

One of the big obstacles to the curves you mentioned was the lack of
vetting. That's gone now: you can point to it in an RFC when this gets
published. As a result when it comes to designing or revising old
standards, it won't be harder than putting any other curve now.

I'm very much against protocol design that involves lots of options: I
like these curves because they have great implementations with
liberal licensing available now. You can use these curves today with
just a choice of big or little endian, and software that sets speed

Adding in the apparatus in each protocol is obviously going to take
longer, depending on how bad the protocol is to work with. But
I don't think CFRG is the right place for that.
> Paul

"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin