Re: [Cfrg] Safecurves draft

Paul Lambert <paul@marvell.com> Thu, 09 January 2014 01:33 UTC

Return-Path: <paul@marvell.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 848011ADF89 for <cfrg@ietfa.amsl.com>; Wed, 8 Jan 2014 17:33:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.567
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGIAorO02rSh for <cfrg@ietfa.amsl.com>; Wed, 8 Jan 2014 17:33:15 -0800 (PST)
Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id 39D9D1ADF0E for <cfrg@irtf.org>; Wed, 8 Jan 2014 17:33:14 -0800 (PST)
Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s091X4bq007906; Wed, 8 Jan 2014 17:33:04 -0800
Received: from sc-owa01.marvell.com ([199.233.58.136]) by mx0b-0016f401.pphosted.com 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 SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Wed, 8 Jan 2014 17:33:00 -0800
From: Paul Lambert <paul@marvell.com>
To: Watson Ladd <watsonbladd@gmail.com>
Date: Wed, 8 Jan 2014 17:32:54 -0800
Thread-Topic: [Cfrg] Safecurves draft
Thread-Index: Ac8M2rsrhRaZOXFQTW2+VzrVMjArbA==
Message-ID: <CEF33A97.2BEC6%paul@marvell.com>
References: <CACsn0cmPj-=bfwCLJXvHSbOS_U5AfZH2vTWfrVsXwOXF4Y9hcg@mail.gmail.com> <52CD8931.9050909@cs.tcd.ie> <CACsn0ck8Vh1t1CKCYy06X0ifW2HYZzB3RXEaQ8f1hF5JhSXFfQ@mail.gmail.com> <e36cdd6ad77b7fcdd7ede78142abf004.squirrel@www.trepanning.net> <7BAC95F5A7E67643AAFB2C31BEE662D018B7ED6F89@SC-VEXCH2.marvell.com> <CACsn0ckY0-k2ajX5W+pesVuBSTDoBcfOB2M-Rp2cZvStbU8MbA@mail.gmail.com> <7BAC95F5A7E67643AAFB2C31BEE662D018B7ED700E@SC-VEXCH2.marvell.com> <CACsn0cnYeFw+PngYVc2aop0CgAHe3xZ-9cf-QGW-L6XM2SUG_Q@mail.gmail.com>
In-Reply-To: <CACsn0cnYeFw+PngYVc2aop0CgAHe3xZ-9cf-QGW-L6XM2SUG_Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.9.131030
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: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] 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 01:33:16 -0000

On 1/8/14, 4:58 PM, "Watson Ladd" <watsonbladd@gmail.com>; wrote:

>On Wed, Jan 8, 2014 at 4:30 PM, Paul Lambert <paul@marvell.com>; 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.
Comment: 
 -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\
         7ff35498a4ab4d6d6ba111301a73faa8537c64c4fd3812f3cbc595
    yG = 0x22
    n  = 2**411 - 
33364140863755142520810177694098385178984727200411208589594759


 


Paul

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
>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
>records.
>
>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