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

[Yumi Sakemi <[e-mail]>]

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 <[e-mail]>:
>
> 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 <[e-mail]>:
> >
> > 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=[e-mail]> wrote:
> >>
> >> On Wed, Jul 8, 2020 at 2:59 PM <[e-mail]> 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
> >> [e-mail]
> >> https://www.irtf.org/mailman/listinfo/cfrg
> >
> > _______________________________________________
> > Cfrg mailing list
> > [e-mail]
> > https://www.irtf.org/mailman/listinfo/cfrg
>
>
>
> --
> Yumi Sakemi, Ph. D.
> Lepidum Co. Ltd.
>
> E-Mail: [e-mail]



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

E-Mail: [e-mail]