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

Yumi Sakemi <> Wed, 05 August 2020 02:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7B0ED3A1211 for <>; Tue, 4 Aug 2020 19:30:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7hpZTHsCTcUK for <>; Tue, 4 Aug 2020 19:30:42 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C0F903A120F for <>; Tue, 4 Aug 2020 19:30:42 -0700 (PDT)
Received: by with SMTP id r21so21661039ota.10 for <>; Tue, 04 Aug 2020 19:30:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=AcvqYrwW7tPHZA/0egeM9nn9nl05eCRMr7mG22nREb8=; b=d+6v94bSegOMb8/osim8PmjkALWC7j8I+ifqhJBETvs5NY/mEiIQI0kfZhn0Bn4yMy XYd0bUUuGCbKVz8FPKeQbuHDUER1W8CA+dxreEcpAqlU2IQ9ctY84tCd3YWZZjDJINrw /hxO0AfybLhgSp+Yz5pcu0SV62f3ojFRv3/915avgZC7L0pAeClcCp9uC4hbzFKtdmDM 1Wu/pjC9bGcsbPUD7jyyZ9C6Fty4fRY4vkreLQy60dDnWwQE+tgSlWvRkjvITPY2HH27 B08HqBh5rBps2KexYQgHidPsDcAg9FCA5KcMwtke1L+X6K4BUgyq1ULvHKMmUu5cqThZ QRGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=AcvqYrwW7tPHZA/0egeM9nn9nl05eCRMr7mG22nREb8=; b=oxxqzDHT/rOZql/AAgU3yX0fxSzCLcQNQ4RqgDfoLICZuFp5utwHQVaH0+cUmFNz9Q Gi4H/G6XoKxHl17YYawrLIkYl822KiowUI0AZp5KQzNgC9FFkDlNbVgejbeu+KwDQekD 7Tk1PgqqZXfHEvzUfDCtA362/Mb1pqOSVMK2cN6+kGSGezarBhgRvBnuSciiMJ4sNnw+ e7fNLVcgGu7GQGLWqHge+/Tq+14jKF1sfXDbtYFVVLI31e9xKhj8DQ1gBHzgJL4Uyku6 duqWPuteMRTEzv2pJgxYxti5EZ6PBmec4/vwFK7zw6wsRSG+yT6ZwAAUiTLerlbTZy64 g/hw==
X-Gm-Message-State: AOAM531YzYPJ96m32b0Tsek7xc9+6i1SA8hY6a4Q5ffWw/hnZBLgROjY qfEUiUz0ym/p0y/iQ3fB06UQWyS2MV/OUAtOwMneOA==
X-Google-Smtp-Source: ABdhPJwp9IzU1lIChcn8DrzueLToJFMZ7Xter42mBxi62Vfpz5ytYO0DLwlaHQcT9KP4HrdH3TvyIh8qIn9k7Nrclss=
X-Received: by 2002:a9d:3f66:: with SMTP id m93mr928481otc.49.1596594641942; Tue, 04 Aug 2020 19:30:41 -0700 (PDT)
MIME-Version: 1.0
References: <> <20200708215916.xbdvyak6etncqxwj@muon> <> <>
In-Reply-To: <>
From: Yumi Sakemi <>
Date: Wed, 5 Aug 2020 11:30:30 +0900
Message-ID: <>
To: Armando Faz <>
Cc: CFRG <>, Tetsutaro Kobayashi <>, SAITO Tsunekazu <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Cfrg] RGLC on draft-irtf-cfrg-pairing-friendly-curves-07
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 05 Aug 2020 02:30:45 -0000

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
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,

2020年7月17日(金) 15:54 Marek Jankowski <>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 <> wrote:
>> On Wed, Jul 8, 2020 at 2:59 PM <> 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 mailing list

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