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

From: Yumi Sakemi <[email-masked]>
Date: Wed, 5 Aug 2020 11:30:30 +0900

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 <[email-masked]>:
>
> 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=[email-masked]> wrote:
>>
>> On Wed, Jul 8, 2020 at 2:59 PM <[email-masked]> 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
>> [email-masked]
>> https://www.irtf.org/mailman/listinfo/cfrg
>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

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

E-Mail: [email-masked]

---

From: Yumi Sakemi <[email-masked]>
Date: Wed, 5 Aug 2020 14:47:36 +0900

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

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