Re: [Cfrg] Suggestions for draft-irtf-cfrg-curves-01.txt

Evgeny Alekseev <eamsucmc@gmail.com> Thu, 12 February 2015 07:39 UTC

Return-Path: <eamsucmc@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 8356A1A9118 for <cfrg@ietfa.amsl.com>; Wed, 11 Feb 2015 23:39:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.701
X-Spam-Level:
X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 jFhTu_vJHIFK for <cfrg@ietfa.amsl.com>; Wed, 11 Feb 2015 23:39:26 -0800 (PST)
Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC8A71A9117 for <cfrg@ietf.org>; Wed, 11 Feb 2015 23:39:25 -0800 (PST)
Received: by mail-yk0-f178.google.com with SMTP id 19so3717146ykq.9 for <cfrg@ietf.org>; Wed, 11 Feb 2015 23:39:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=btOQYr1C5aaEt+TrBD+22LbGq9mEfOs2ruy/fuwWLz0=; b=ZPyUm5Fmaqa1BwoBBkBNmB35r7bvKEWOrKpRaahwx7PvxA9/cq6JswhR4TmEBEg6VS Cvzv0yZgoCBBa2xFdYE52u0blyg5VO4bknss4mrYZQWYtr6Dfw7FDXOtce5yntEz7U6n q8zGk8A5KGx3kzBBdTrEovNTrmuxv+h2pu2h5B5XMcOVGyKmhX1mwQlslUkA+Gi4HVva ZRsfIoaz1/OeYEcNee2BqH9mm/lE+HUBx6suSMJWmkr+Tr518a62xSkaAjBV1OIe9k86 suig3Fd2+wcFeGsTIusHEidH/jPMLGEqZu61Vydfrvr8So+LJvafH4P893+laOPNw0lk k23w==
MIME-Version: 1.0
X-Received: by 10.236.26.16 with SMTP id b16mr2200928yha.50.1423726764974; Wed, 11 Feb 2015 23:39:24 -0800 (PST)
Received: by 10.170.202.136 with HTTP; Wed, 11 Feb 2015 23:39:24 -0800 (PST)
In-Reply-To: <D0F51314.5A84F%paul@marvell.com>
References: <CAOVPyjxPUhF1mK9C3vEbM4ABxW0P46Wi7JxQSbFRF01i45WmQg@mail.gmail.com> <CACsn0cm2zktOjrqBXYfFLij_-C3vwmk7oDsqJwMvc4MxUa3oRA@mail.gmail.com> <D0F51314.5A84F%paul@marvell.com>
Date: Thu, 12 Feb 2015 10:39:24 +0300
Message-ID: <CAOVPyjym6RPnCB-uhZC65q=kNuFsGTVouX-GLgsdoSSE22S9Jw@mail.gmail.com>
From: Evgeny Alekseev <eamsucmc@gmail.com>
To: "cfrg@ietf.org" <cfrg@ietf.org>
Content-Type: multipart/alternative; boundary=089e013d06ce15685f050edf38d5
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/2gY79GCFBWMWy4Bf9ic3snqLNyA>
Subject: Re: [Cfrg] Suggestions for draft-irtf-cfrg-curves-01.txt
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, 12 Feb 2015 07:39:31 -0000

>> Q1: Should CFRG recommend a curve at the 192-bit security level?
Possibly

>> Q2: Should CFRG recommend a curve at the 256-bit security level?
Yes

I don't really think that specification of a new 512-bit curve will
take too many time. Method and requirements
can be similar to ones used for 256-bit (maybe cofactors’ pair will be
(16,16) and (16,8) or something like
these). At the same time 521-bit curve seems kind of strange for me
because speed advantage is not too crucial
but implementation of such arithmetic may be much harder on some
architectures – and it can really delay
incorporation of such curves in some hardware solutions.

Kind regards, Evgeny Alekseev, PhD
Moscow State University, Faculty of Computational Mathematics and Cybernetics


2015-02-02 23:04 GMT+03:00 Paul Lambert <paul@marvell.com>:

>
>
> On 2/2/15, 8:35 AM, "Watson Ladd" <watsonbladd@gmail.com> wrote:
>
> >On Mon, Feb 2, 2015 at 7:07 AM, Evgeny Alekseev <eamsucmc@gmail.com>
> >wrote:
> >> Stanislav V. Smyshlyaev wrote:
> >>
> >>> Dear colleagues,
> >>>
> >>> We would like you to consider several proposals on the latest variant
> >>>of
> >>> draft (draft-irtf-cfrg-curves-01).
> >>>
> >>> 1)      In our opinion, some important clarifications have to be done
> >>> explicitly in the document, though needed references are given.
> >>>  a) In Section 3.3 declare explicitly what "r² denotes.
> >>>  b) In Section 5 mention explicitly Schoof­Elkies­Atkin algorithm as an
> >>> algorithm used to calculate number of curve points or even fully cite
> >>>it
> >>> there.
> >>>  c) Add explicit description of algorithms used to examine curve on
> >>>MOV-,
> >>> CM- and twist-security as well as Frobenius trace calculation formula.
> >>>Add
> >>> ³perform checks² step in algorithms proposed in sections 5.1 and 5.2.
> >>> 2)      Select and add a higher security curve (512- or 521-bit).
> >>> 3)      Add some explanations on parameter d of the selected 255-bit
> >>>curve
> >>> (the current draft leaves the question whether it is the first d to be
> >>> returned by 5.2 algorithm and the reason of choice if it is not).
> >>> 4)      Introduce a rigid base point generation algorithm (either the
> >>>one
> >>> that was proposed in the previous version of the draft or one using
> >>> cryptographic hash function). We consider that important to ensure the
> >>> generated points > could be safely used in applied protocols like
> >>> password-based key establishment protocols (PAKE, EKE, PACE etc.) and
> >>>RNGs
> >>> like Dual EC DRBG.
> >>>
> >>>
> >>> Best regards,
> >>> Stanislav V. Smyshlyaev, Ph.D.,
> >>> Head of Information Security Department,
> >>> CryptoPro LLC
> >>
> >>
> >> I agree with Stanislav Smyshlyaev¹s questions and suggestions about
> >>current
> >> draft version. I would like to draw attention to the 3d remark. If the
> >> answer to this question ("... whether it is the first d to be returned
> >>by
> >> 5.2 algorithm ...") is ³no² then it turns out that extra requirements
> >>that
> >> are not mentioned in the draft are implicitly applied to the curve.
> >>Also it
> >> seems strange that the recommended curve is not the one with the
> >>smallest d,
> >> but the isogeny of this curve. Also I would like to add that it would be
> >> convenient if the recommended Edwards curve is included in the document
> >>in
> >> the same way as twisted Edwards curve.
>
> +1
>
> >
> >The recommended curve is y^2=x^3+486662x^2+x. Were we to use an
> >isomorphic curve, as opposed to a 4-isogenous one, that 486662 would
> >be replaced by a larger number, and thus slow down implementations
> >significantly. Note that 486662 is the smallest value of a that
> >ensures that
> >y^2=x^3+ax^2+x has order 8*prime, twist order 4*prime, and the usual
> >CM restrictions. This is the same as 121665 being the smallest d that
> >ensure that y^2+x^2=1+dx^2y^2 has the same order and CM restrictions.
>
> So Š the designated editing team will process the above answer
> and create suitable text for possible inclusion into the
> draft specification.  Yes?
>
> Paul
>
>
> >
> >Sincerely,
> >Watson Ladd
> >
> >>
> >> Kind regards, Evgeny Alekseev, Doctor of Philosophy,
> >> Moscow State University, Faculty of Computational Mathematics and
> >> Cybernetics
> >>
> >>
> >>
> >> _______________________________________________
> >> Cfrg mailing list
> >> Cfrg@irtf.org
> >> http://www.irtf.org/mailman/listinfo/cfrg
> >>
> >
> >
> >
> >--
> >"Those who would give up Essential Liberty to purchase a little
> >Temporary Safety deserve neither  Liberty nor Safety."
> >-- Benjamin Franklin
> >
> >_______________________________________________
> >Cfrg mailing list
> >Cfrg@irtf.org
> >http://www.irtf.org/mailman/listinfo/cfrg
>
>