Re: [Crypto-panel] Request for review: draft-irtf-cfrg-pairing-friendly-curves-03

[Yumi Sakemi <[e-mail]>]

Dear Alexey, Nick, Stanislav, and Chloe

We have submitted the latest version 05 of the draft "Pairing-Friendly Curves".
https://datatracker.ietf.org/doc/draft-irtf-cfrg-pairing-friendly-curves/

We have categorized a lot of comments received in the Expert Review
into more than 40 issues, and reflected the results which we
considered all of issues to the latest version.
While we revised the draft, we received comments from other CFRG
members and the authors of the draft "BLS Signatures", and reflected
them to the latest version.

If you want to know the details of how to revise, you can check them
by closed issues on the official CFRG GitHub page.

https://github.com/cfrg/draft-irtf-cfrg-pairing-friendly-curves/issues?q=is%3Aissue+is%3Aclosed

Thanks to valuable and constructive comments from Chloe and CFRG
members, our draft became readable and higher quality.
We strongly believe that the draft is ready for RG Last Call.
If there are other necessary procedures for RGLC, could you tell us?

Best regards,
Yumi

2020年6月9日(火) 20:02 Yumi Sakemi <[e-mail]>:
>
> Dear Chloe
>
> Thank you for your e-mail.
>
> We are very glad to reach a rough consensus with you.
> We believe that our draft became very readable and higher quality by
> reflecting your comments.
> We appreciate your valuable and constructive comments.
>
> We'd like to express our gratitude and include your name in Acknowledgement.
> The version 05 that is reflected your comments will be submitted today
> or tomorrow, then we will contact you again.
>
> Best regards,
> Yumi
>
> 2020年6月1日(月) 18:53 Chloe Martindale <[e-mail]>:
> >
> > Dear Yumi, dear all,
> >
> > thank you for the update and for involving me in your thought process regarding the curve choices. I understand and agree with your reasoning (and approach) regarding including both BLS12-381 and BN462, however I think I would make a different 'safer choice'.
> >
> > My reason is this: if the attack is improved further (which you are completely right, it may), it is very likely to have a bigger impact on curves constructed via polynomial methods with embedding degree 8 (such as BN462) than on any other curves for this security level, so it's not unlikely that the security of BN462 would be pushed below 128 bits. A safer choice in my view would be to take the Cocks-Pinch curve (not constructed using polynomial methods) defined using a 544-bit prime implemented in RELIC, from [GMT19]*. The TNFS attacks cannot be applied to Cocks-Pinch curves (at least not without a fundamental new attack idea, since they rely on the polynomial construction), so small improvements will not decrease the security level at all, and this curve is actually still more efficient than BN462 so there's nothing to lose there. I appreciate that such a choice would mean also including some background on Cocks-Pinch and a reference/short explanation of the fact that TNFS attacks don't apply to these, which would be a major change to the original document, so I appreciate it if you'd rather not do this, but just thought I'd suggest it as I think it would increase the lifetime of your document.
> >
> > *In your draft this is [GME19], but it should be [GMT19], and can now be updated to the peer-reviewed version of course (this is the paper I pointed out in my review).
> >
> > All the best,
> > Chloe
> >
> > On Fri, 29 May 2020 at 16:21, Yumi Sakemi <[e-mail]> wrote:
> >>
> >> Dear Chloe
> >>
> >> We appreciate a lot of constructive comments received at Expert Review.
> >>
> >> We are currently working on updating our draft.
> >> Last week, Nick created a repository for pairing-friendly curves on
> >> CFRG's official GitHub, so we plan to update our draft using the issue
> >> tracker.
> >> The updating for your comments will be made available to you on the
> >> following issue page.
> >>
> >> https://github.com/cfrg/draft-irtf-cfrg-pairing-friendly-curves/issues
> >>
> >> We will contact you again when all the comments have been updated.
> >> In that case, we would be glad if you could check them.
> >>
> >> In addition, before updating, there is a comment that we would like to
> >> inform you about the policy of update.
> >> The comment is about the recommended curve for 128-bit security level.
> >>
> >> First of all, thank you for teaching us a peer-reviewed paper for BLS12-381.
> >> The comment is about the recommended curve for 128-bit security level.
> >> Due to our lack of investigation, we made the wrong decision that
> >> BLS12-381 was not matched in our selection policy.
> >>
> >> Your comment pointed out that BLS12-381 is moved to the recommended
> >> curve and BN462 is moved to the Appendix.
> >> We understood the disadvantages of BN462 that you were concerned
> >> about, but we would like to recommend both BLS12-381 and BN462.
> >> The reason is as follows.
> >>
> >> CFRG aims to standardize cryptographic technology for future Internet use.
> >> We agree that BLS12-381 with a 126-bit security level is the best
> >> match as a curve of 128-bit security level "at this time" from the
> >> viewpoint of security and efficiency.
> >> On the other hand, the security of BLS12-381 is already less than
> >> 128bit, so from the viewpoint of future use, if the attack is improved
> >> even a little, it will not be suitable for a curve of 128-bit security
> >> level.
> >> Considering that the curve of 128-bit security level is often used at current.
> >> So, we would like to recommend both BLS12-381 and BN462 considering
> >> the future use and the safety side.
> >>
> >> However, as you pointed out, BN462 has the disadvantage of being too
> >> slow compared to BLS12-381.
> >> Then, the reader will be confused if there are two parameters of
> >> 128-bit security level, so we will add the basis for selection by
> >> adding the explanation of merits and demerits for each parameter.
> >> And, we will also add a description about the disadvantages of BN462
> >> regarding efficiency.
> >>
> >> If you have any problems with the updating policy, we would like you to comment.
> >>
> >> Best regards,
> >> Yumi
> >>
> >>
> >>
> >>
> >>
> >>
> >> 2020年4月27日(月) 21:58 Yumi Sakemi <[e-mail]>:
> >> >
> >> > Dear Chloe
> >> >
> >> > I appreciate your review.
> >> > I'm very glad to receive many constructive comments!
> >> > I will discuss about your comments with co-authors and revise our
> >> > draft to reflect your comments in our draft.
> >> > I think it will be a better draft by reflecting your comments.
> >> >
> >> > As co-author Tsunekazu e-mailed, we're  planning to submit version 04,
> >> > because we were independently working on updating of abstract,
> >> > introduction (sec. 1.3) and proofreading of English in parallel with
> >> > the expert review.
> >> > (Version 04 will not be reflected your comments.)
> >> >
> >> > Comments from Chloe will be reflected in the version 05.
> >> > We will submit version 05 in mid-May and we will report you when we
> >> > submit version 05.
> >> >
> >> > Dear Stanislav
> >> >
> >> > Thank you very much for proceeding to the Expert review.
> >> > We received a lot of constructive comments from Chloe, so I think it
> >> > is difficult to manage comments by email.
> >> > (Because there are over 100 comments from Chloe.)
> >> >
> >> > Therefore, I would like to use the issue management function of GitHub
> >> > so that it is easy to check the reflecting status of Chloe's comments.
> >> > So, I'd like to use the repository of pairing-friendly curves draft on
> >> > CFRG's GitHub
> >> > because BLS signature which is similar in terms of IRTF stream is also
> >> > registered on the GitHub.
> >> > Could you register the repository for the draft of pairing-friendly
> >> > curves on the following CFRG's GitHub?
> >> >
> >> > https://github.com/cfrg
> >> >
> >> > Best regards,
> >> > Yumi
> >> >
> >> > 2020年4月27日(月) 10:09 SAITO Tsunekazu <[e-mail]>:
> >> > >
> >> > > Dear Chloe, Stanislav,
> >> > >
> >> > >
> >> > >
> >> > > This is Tsunekazu.
> >> > >
> >> > >
> >> > >
> >> > > We plan to update the draft to version 04 soon.
> >> > >
> >> > > As the contents of the update, we changed the wording of Section 1.3 and security consideration.
> >> > >
> >> > > Yumi will submit the 4th edition, so please wait a moment.
> >> > >
> >> > >
> >> > >
> >> > > Best regards,
> >> > >
> >> > > Tsunekazu
> >> > >
> >> > >
> >> > >
> >> > > From: Stanislav V. Smyshlyaev <[e-mail]>
> >> > > Sent: Sunday, April 26, 2020 2:30 PM
> >> > > To: Chloe Martindale <[e-mail]>; SAITO Tsunekazu <[e-mail]>; Tetsutaro Kobayashi <[e-mail]>; Yumi Sakemi <[e-mail]>
> >> > > Cc: [e-mail]; [e-mail]
> >> > > Subject: Re: [Crypto-panel] Request for review: draft-irtf-cfrg-pairing-friendly-curves-03
> >> > >
> >> > >
> >> > >
> >> > > Dear Chloe,
> >> > >
> >> > > Many thanks for your review (such a great and a prompt one!).
> >> > >
> >> > >
> >> > >
> >> > > Dear Yumi, Saito, Tetsutaro, do you plan to update your draft taking into account Chloe’s review?
> >> > >
> >> > >
> >> > >
> >> > > Best regards,
> >> > >
> >> > > Stanislav
> >> > >
> >> > >
> >> > >
> >> > > пт, 24 апр. 2020 г. в 19:49, Chloe Martindale <[e-mail]>:
> >> > >
> >> > > Hi all,
> >> > >
> >> > >
> >> > >
> >> > > review is attached.
> >> > >
> >> > >
> >> > >
> >> > > All the best,
> >> > >
> >> > > Chloe
> >> > >
> >> > >
> >> > >
> >> > > On Tue, 21 Apr 2020 at 18:05, Stanislav V. Smyshlyaev <[e-mail]> wrote:
> >> > >
> >> > > Sure - it is
> >> > >
> >> > > https://tools.ietf.org/html/draft-irtf-cfrg-pairing-friendly-curves-03
> >> > >
> >> > >
> >> > >
> >> > > Thank you again!
> >> > >
> >> > >
> >> > >
> >> > > Regards,
> >> > >
> >> > > Stanislav
> >> > >
> >> > >
> >> > >
> >> > > вт, 21 апр. 2020 г. в 19:10, Chloe Martindale <[e-mail]>:
> >> > >
> >> > > Just to be sure, can you point me towards the most recent version of the draft please?
> >> > >
> >> > >
> >> > >
> >> > > Thanks,
> >> > >
> >> > > Chloe
> >> > >
> >> > >
> >> > >
> >> > > On Tue, 21 Apr 2020 at 13:17, Stanislav V. Smyshlyaev <[e-mail]> wrote:
> >> > >
> >> > > Great, many thanks, Chloe!
> >> > >
> >> > >
> >> > >
> >> > > Kind regards,
> >> > >
> >> > > Nick, Alexey, Stanislav
> >> > >
> >> > >
> >> > >
> >> > > On Tue, 21 Apr 2020 at 15:16, Chloe Martindale <[e-mail]> wrote:
> >> > >
> >> > > I'll take a look this week.
> >> > >
> >> > >
> >> > >
> >> > > All the best,
> >> > >
> >> > > Chloe
> >> > >
> >> > >
> >> > >
> >> > > On Tue, 21 Apr 2020, 13:10 Stanislav V. Smyshlyaev, <[e-mail]> wrote:
> >> > >
> >> > > Dear Crypto Panel members,
> >> > >
> >> > >
> >> > >
> >> > > The authors of the Pairing-Friendly Curves draft have addressed the concerns raised during the discussion and are ready to move to the next stage with the draft.
> >> > >
> >> > >
> >> > >
> >> > > Alexey, Nick and I would like to ask Crypto Review Panel members about the review(s) of draft-irtf-cfrg-pairing-friendly-curves-03.
> >> > >
> >> > >
> >> > >
> >> > > This memo introduces pairing-friendly curves used for constructing pairing-based cryptography. It describes recommended parameters for each security level and recent implementations of pairing-friendly curves.
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > Can we have any volunteers, please?..
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > Best regards,
> >> > >
> >> > > Stanislav (on behalf of chairs)
> >> > >
> >> > > _______________________________________________
> >> > > Crypto-panel mailing list
> >> > > [e-mail]
> >> > > https://www.irtf.org/mailman/listinfo/crypto-panel
> >> >
> >> >
> >> >
> >> > --
> >> > Yumi Sakemi, Ph. D.
> >> > Lepidum Co. Ltd.
> >> > E-Mail: [e-mail]
> >>
> >>
> >>
> >> --
> >> Yumi Sakemi, Ph. D.
> >> Lepidum Co. Ltd.
> >>
> >> E-Mail: [e-mail]
>
>
>
> --
> Yumi Sakemi
> Lepidum Co. Ltd.
>
> E-Mail: [e-mail]



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

E-Mail: [e-mail]