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, 05 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>: > > 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>: > > > > 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
- [Cfrg] RGLC on draft-irtf-cfrg-pairing-friendly-c… Stanislav V. Smyshlyaev
- Re: [Cfrg] RGLC on draft-irtf-cfrg-pairing-friend… Stanislav V. Smyshlyaev
- Re: [Cfrg] RGLC on draft-irtf-cfrg-pairing-friend… Armando Faz
- Re: [Cfrg] RGLC on draft-irtf-cfrg-pairing-friend… rsw
- Re: [Cfrg] RGLC on draft-irtf-cfrg-pairing-friend… Armando Faz
- Re: [Cfrg] RGLC on draft-irtf-cfrg-pairing-friend… Rene Struik
- Re: [Cfrg] RGLC on draft-irtf-cfrg-pairing-friend… Michael Scott
- Re: [Cfrg] RGLC on draft-irtf-cfrg-pairing-friend… Yumi Sakemi
- Re: [Cfrg] RGLC on draft-irtf-cfrg-pairing-friend… Stanislav V. Smyshlyaev
- Re: [Cfrg] RGLC on draft-irtf-cfrg-pairing-friend… Marek Jankowski
- Re: [Cfrg] RGLC on draft-irtf-cfrg-pairing-friend… Yumi Sakemi
- Re: [Cfrg] RGLC on draft-irtf-cfrg-pairing-friend… Yumi Sakemi
- Re: [Cfrg] RGLC on draft-irtf-cfrg-pairing-friend… Yumi Sakemi