Re: [Cfrg] Safecurves draft

Paul Lambert <> Thu, 09 January 2014 01:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 848011ADF89 for <>; Wed, 8 Jan 2014 17:33:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.567
X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hGIAorO02rSh for <>; Wed, 8 Jan 2014 17:33:15 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 39D9D1ADF0E for <>; Wed, 8 Jan 2014 17:33:14 -0800 (PST)
Received: from pps.filterd ( []) by (8.14.5/8.14.5) with SMTP id s091X4bq007906; Wed, 8 Jan 2014 17:33:04 -0800
Received: from ([]) by with ESMTP id 1h919ravby-22 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 08 Jan 2014 17:33:04 -0800
Received: from ([]) by ([]) with mapi; Wed, 8 Jan 2014 17:33:00 -0800
From: Paul Lambert <>
To: Watson Ladd <>
Date: Wed, 08 Jan 2014 17:32:54 -0800
Thread-Topic: [Cfrg] Safecurves draft
Thread-Index: Ac8M2rsrhRaZOXFQTW2+VzrVMjArbA==
Message-ID: <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-01-09_01:2014-01-07, 2014-01-09, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1401080178
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 01:33:16 -0000

On 1/8/14, 4:58 PM, "Watson Ladd" <> wrote:

>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
>> 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.
 -too terse
 - no clear mapping of numbers to variables
 - no documentation of Edwards point addition
   Which is different from durrent ECC drafts
 - no indication of security concerns and
  need or lack of checking public key values

Here¹s how I¹d document curve parameters:

class Curve3617(EdwardsCurveFp):
    curveId  = 'curve3716'
    strength = 207
    oid = None
    p  = 2**414 - 17
    d  = 3617
    xG = 0x1a334905141443300218c0631c326e5fcd46369f44c03ec7f5\
    yG = 0x22
    n  = 2**411 - 



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

>Take a good look for typos: that's what can really mess this whole thing
>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
>> 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