Re: [Cfrg] RGLC on draft-irtf-cfrg-pairing-friendly-curves-07

Yumi Sakemi <yumi.sakemi@lepidum.co.jp> Wed, 05 August 2020 05:47 UTC

Return-Path: <yumi.sakemi@lepidum.co.jp>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046AB3A1319 for <cfrg@ietfa.amsl.com>; Tue, 4 Aug 2020 22:47:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lepidum-co-jp.20150623.gappssmtp.com
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 OfeUBOVe1ta4 for <cfrg@ietfa.amsl.com>; Tue, 4 Aug 2020 22:47:48 -0700 (PDT)
Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (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 06FAF3A1318 for <cfrg@irtf.org>; Tue, 4 Aug 2020 22:47:47 -0700 (PDT)
Received: by mail-ot1-x32e.google.com with SMTP id k12so15617799otr.1 for <cfrg@irtf.org>; Tue, 04 Aug 2020 22:47:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lepidum-co-jp.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=nU6FF+O/DEkS/vrIyY4F0ZqAwcXILgBV9OVaJThFi2k=; b=rcC4B7lKET2MQ2TJSU4xYPdkMiS2Zm/wOK1gq8xe2cUYlZvCU2a9z7JDaD5DylojkU QOpbSCDIAFcU/6nFajqy+K0LIT/4smGfyvjxEE7jlKOABDplbaTI98HPW9ecol/wUJxU 6VYdg7FQKwW21rs0F2bzMRbZKoB5Yf6QusOsIeALF66GPYV0XU4z5F2kKYRr0GOtFcJC sHyAFQGfLv0XHUNSD8vBtO8rq3TWOyri4cMPAi7GoecEAImsQnJ4NN9k5WUYb/JjXBgp uqiLTIRc/5q1j7rUDYEDgohuOxJ/vgVkJHrJTiLANGn0bxkQJ+Hp2bADAoVAh5HbyfYl 5A9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=nU6FF+O/DEkS/vrIyY4F0ZqAwcXILgBV9OVaJThFi2k=; b=kCxcu/dXnuXeCLnQa+Jmk/JpbohDpNS0884CMxGWgfN1iZ+2lwySbHL6cwnoWagQ/l w3hSH0iJyOYz65Jzc11q1qKPJWlhJSVHY/svE//CpQHu93gVqJQqpYDqvz7rGAJbce8k VsUVwsvqSkp/7FPSdmq8/OJQEoMzEp141q+p6n6s2zRakaByhbCfgHiArHbkCad4rdnQ 4YlFOxqiMiZ+PHr6VaZZ1TIXeyKK2K+Vs5yBZ+Kn/pdTLx02gQu9MgnlDIuKOqNXSdH/ mJayLSGgwB87sRCd08BflCkWF7m1P6albwT+sWF0ier6xjaQq1fxRaQvbT1VmQg68JeA UAyg==
X-Gm-Message-State: AOAM531fwatrJK0Wm4AXrQgRVkQh7r/Gm53PH16bBKE2zYHcFthJcaSb 6BQUTzmwMNEnM89DAVS30eQPncAEs05XlfGYjtnUAw==
X-Google-Smtp-Source: ABdhPJzHH2ocAwrV9etAWABSrzUBuoweNe+lZ1QYyBnw46cQ+GXxTsRxvuMxM0nR/lOfxUFywNGa28PduC1uQ1nVDyw=
X-Received: by 2002:a9d:3f66:: with SMTP id m93mr1383284otc.49.1596606466863; Tue, 04 Aug 2020 22:47:46 -0700 (PDT)
MIME-Version: 1.0
References: <CABZxKYmyYbOXG9Lo8vNZANn=x+DhZR0qztAg+JbYnLdoxVrsTQ@mail.gmail.com> <20200708215916.xbdvyak6etncqxwj@muon> <CABZxKYnnu6F0+zSZZ1NmmFgaNhf=J5f3CxMQRNXtBOiP6SpPMA@mail.gmail.com> <CAMCcN7RMQKzjdGZQAnxr2a0=0y5D9AXqsNbnLwMwd-GtGSMzwA@mail.gmail.com> <CAA4D8KbESQRaCycjTKkkAvu7Xs6+NgVXrh58vCSaLLwhXYLc_w@mail.gmail.com>
In-Reply-To: <CAA4D8KbESQRaCycjTKkkAvu7Xs6+NgVXrh58vCSaLLwhXYLc_w@mail.gmail.com>
From: Yumi Sakemi <yumi.sakemi@lepidum.co.jp>
Date: Wed, 5 Aug 2020 14:47:36 +0900
Message-ID: <CAA4D8KYpcZYXW+BJCqztOjs6FGjhFeY9Ok_G_pc6qzof1NgRUA@mail.gmail.com>
To: mjankowski309@gmail.com
Cc: CFRG <cfrg@irtf.org>, Tetsutaro Kobayashi <tetsutaro.kobayashi.dr@hco.ntt.co.jp>, SAITO Tsunekazu <tsunekazu.saito.hg@hco.ntt.co.jp>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/xct-m8L2xjTo5zDKqHKBnb_1_qA>
Subject: Re: [Cfrg] RGLC on draft-irtf-cfrg-pairing-friendly-curves-07
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Aug 2020 05:47:50 -0000

Dear Marek

Thank you for your e-mail!

We will accept the suggestions about "hash to curve" from Armando and
add a reference of the draft "hash to curve" in the draft
"pairing-friendly curves".

Also, I appreciate encouraging our standardization activities!
I would like to try my best!

Best regards,
Yumi

2020年8月5日(水) 11:30 Yumi Sakemi <yumi.sakemi@lepidum.co.jp>jp>:
>
> Dear Armando
>
> We appreciate your comments on the draft of the pairing-friendly curves.
> I'm so sorry for the late reply.
> We had a discussion with the co-authors.
>
> I understand that we received three major comments from you.
> The followings are reply comments.
>
> 1. About 128bit parameters
> Thank you for proposing your recommended curve.
> As you pointed out, we understand that the BLS12-461 also has merits.
> On the other hand, we would like to introduce the following merits of BN462.
>
> The advantage of BLS462 is about the parameters "cofactors".
> In the case of BN462, the order r that is used for pairing and the
> order of the elliptic curve on Fp are almost the same, so there is no
> waste.
> That is, so advantageous for random generation of rational points on G1.
> As for the cofactor of G2, the order of the BLS curve is larger than
> the BN curve
> because log(2, h_2) = 461 for BN462 and log(2, h_2) = 585 for BLS12-462.
>
> As for the performance, acceleration techniques and performance are
> improving day by day,
> so we believe that there is no real problem in practical use.
> Therefore, the selection policies are more emphasized "security" and
> "widely-used" than performance.
>
> About implementation compatibility, as you pointed out,
> implementations can move from BLS12-381 to BLS12-461 just by replacing
> the field arithmetic layer.
> On the other hand, BN462 is compatible with BN254, which is currently
> the most implemented parameter.
> BN254 is also adopted by some international standards such as the TCG,
> ISO, and FIDO,
> and it is expected that many organizations have implementations of BN curves.
>
>
> 2. About suites of hash to curves
>
> Thank you for your comments.
> We would like to refer to the draft "hash to curve" in our draft.
>
> Regarding the draft "hash to curve", section 8.8 says that
> "The curve parameters in this section match the ones listed in
> [I-D.irtf-cfrg-pairing-friendly-curves], Appendix C.".
> Please note that the BLS12-381 has returned to the main part from
> Appendix C in our draft.
>
> 3. About 192bit parameters
>
> The fact of implementation is treated as one of the evidence for
> "widely used", which is one of the selection policies.
> As a "widely used" curve, we selected the recommended curves based on
> whether it is adopted by other standards,
> and adopted by the applications,
> and implemented by the implementer.
>
> If we assume the future implementations of new curves,  there is no
> end to the discussion.
> Therefore, we select the recommended curves from the current adoption status.
>
> Finally, it is very helpful to have some minor comments.
> We will use it as a reference for revising the draft.
> In particular, I would like to apologize for my mistyping on your name.
> We will carefully fix it.
>
> Best regards,
> Yumi
>
> 2020年7月17日(金) 15:54 Marek Jankowski <mjankowski309@gmail.com>om>:
> >
> > I agree with Armando.
> > It seems to me that hash-to-curve's main use case is pairings, so defining it in the pairings draft does not make much sense.
> > So the best practice would be to suggest suites and refer to the hash-to-curve draft for more information.
> > As Armando says it is important to refer to the draft mainly to prevent naive use of rejection sampling.
> >
> > Other than that, I think it is a great draft and I support its adoption.
> >
> > Marek
> >
> > On Thu, Jul 9, 2020 at 10:46 PM Armando Faz <armfazh=40cloudflare.com@dmarc.ietf.org> wrote:
> >>
> >> On Wed, Jul 8, 2020 at 2:59 PM <rsw@jfet.org> wrote:
> >> >
> >> > Since neither hash-to-curve nor pairing-friendly-curves is finalized,
> >> > it seems like these hash-to-curve suites could go in either document.
> >>
> >> Additionally to the list the suites (in either document). The pairing
> >> draft should mention somewhere that hash to G1 and G2 are common
> >> operations in several cryptographic protocols. Obviously, it should
> >> point to the hash_to_curve draft, and reinforce the security dangers
> >> of the try-and-increment method, which was popularized in the
> >> pairing-crypto community.
> >>
> >> --
> >> Armando Faz
> >> Cloudflare Inc.
> >>
> >> _______________________________________________
> >> Cfrg mailing list
> >> Cfrg@irtf.org
> >> https://www.irtf.org/mailman/listinfo/cfrg
> >
> > _______________________________________________
> > Cfrg mailing list
> > Cfrg@irtf.org
> > https://www.irtf.org/mailman/listinfo/cfrg
>
>
>
> --
> Yumi Sakemi, Ph. D.
> Lepidum Co. Ltd.
>
> E-Mail: yumi.sakemi@lepidum.co.jp



-- 
Yumi Sakemi, Ph. D.
Lepidum Co. Ltd.

E-Mail: yumi.sakemi@lepidum.co.jp