Re: [CFRG] Second RGLC on draft-irtf-cfrg-pairing-friendly-curves

[Yumi Sakemi <[e-mail]>]

Dear Uri,

Thank you for your message.

I think that the assessment of quantum computing is different from the
purpose of our I-D.
I'm very sorry, but why not discuss it in another thread?

For reference, I would like to share the following URL.
https://mailarchive.ietf.org/arch/msg/cfrg/eLiK6YN4PxRHAlrAzvq4o7L1Lwc/

Best regards,
Yumi

2021年9月14日(火) 3:52 Blumenthal, Uri - 0553 - MITLL <[e-mail]>:
>
> Based on the current progress in the Quantum Computing research, I conjecture that crypto-threatening quantum computers will come to existence, possibly within a decade or two.
>
> Following that conjecture, the useful lifetime of any product that utilizes pairings is likely to be short: after all the time spent on standardizing and refining the standard, implementing it, deploying, getting consumer market to embrace the technology - I conjecture that the actual time of "safe usage" would be at most a few years. Is it worth it? My answer is "no".
>
> --
> Regards,
> Uri
>
>
> On 9/13/21, 14:44, "CFRG on behalf of Yumi Sakemi" <[e-mail] on behalf of [e-mail]> wrote:
>
>     Dear Rene and Watson
>
>     I'm so sorry for my late reply.
>     Thank you for your comments.
>     I checked and discussed with my co-authors about comments from Rene and Watson.
>     As a result, we came up with the idea that the position of our I-D
>     might be different from what Rene and Watson commented on our I-D.
>     Below are the stances we understand when making comments from Rene and
>     Watson and the positions/stances of our I-D.
>
>     - Rene's stance
>     It is the point of view that the I-D should be for educational
>     purposes regarding pairing.
>     For example, the quality of the I-D is inadequate for a textbook and
>     inappropriate for an IRTF draft.
>
>     - Watson's stance
>      Standardization of pairing implementation.
>      For example, there is a lack of detailed explanation of the
>     implementation method in the I-D.
>
>     To be clarified by Prof. Colin and Stanislav in the 2nd RGLC, the
>     stance of our activities is to make an informational RFC
>     about “secure parameters of pairing-friendly curves” promoting Secure
>     Pairing Cryptography on the Internet.
>
>     Kim's attack in 2016 led to a review of the security of pairing-friendly curves
>     no matter how there are still many implementations that contain
>     insecure parameters.
>     To solve this problem, we focus on providing an informative document
>     that implementers of
>     pairing-based cryptographies can refer to when selecting secure parameters.
>     Therefore, it is out of our scope in our I-D that a specific document
>     aimed at standardization and education of pairing algorithms.
>
>     We would appreciate it if you could reconfirm the stance and purpose of our I-D.
>
>     Best regards,
>     Yumi
>
>
>     <<FOR YOUR INFORMATION>>
>     In the following, I would like to explain the background and purpose
>     of our activities again for your reference.
>     As shown in our I-D, there are many kinds of types and parameters for
>     pairing-friendly curves, and it is difficult for implementers of
>     pairing-based cryptographies to select which parameter is secure.
>     For example, the parameters of pairing-friendly curves given in
>     standard specifications such as ISO and TCG have not been updated
>     since before Kim's attack in 2016, so implementers may refer to
>     insecure and inappropriate parameters when referring to these standard
>     specifications.
>     To address this issue, we propose to publish RFC for secure parameters
>     of pairing-friendly curves so that pairing implementors can safely
>     select secure parameters.
>
>     The proposed parameters in our I-D were selected based on the
>     selection policy of "security" and "widely used" after organizing the
>     security of parameters of pairing-friendly curves shown in standard
>     specifications, libraries, and applications.
>
>     On the other hand, again, we do not aim to standardize the method of
>     pairing implementation.
>     A pairing implementation consists of many arithmetic operations,
>     including operations on finite fields, twist techniques, operations on
>     elliptic curves, pairing operations, and applications of pairing.
>     Since many approaches to accelerate each type of operation have been
>     proposed, we don't want to limit the implementation methods in our
>     I-D.
>     Nevertheless, the existence of methods to improve the efficiency of
>     pairing computation is useful as references, so we have made
>     references to textbooks, papers, and other publications to present
>     carefully selected information.
>     Another way to look at it is that acceleration methods may have
>     patents against them, so we avoid such risks.
>
>     2021年9月10日(金) 7:43 Watson Ladd <[e-mail]>:
>     >
>     > On Fri, Aug 13, 2021 at 11:40 AM Stanislav V. Smyshlyaev
>     > <[e-mail]> wrote:
>     > >
>     > > Dear CFRG participants,
>     > >
>     > > This message starts a second RGLC on "Pairing-Friendly Curves" (draft-irtf-cfrg-pairing-friendly-curves-10), that will end on September, 8th.
>     > >
>     > > See https://datatracker.ietf.org/doc/draft-irtf-cfrg-pairing-friendly-curves/ for the latest version of the draft.
>     > >
>     > > We are having the second RGLC since Yumi Sakemi has provided (see https://mailarchive.ietf.org/arch/msg/cfrg/-1nTbbVRlkP5wV2odEYFac-jK08/) updated replies for the questions raised after the first RGLC.
>     > >
>     > > Please send your comments, as well as expression of support to publish as an RFC (or possible reasons for not doing so) in reply to this message or directly to CFRG chairs.
>     >
>     > The timing of this WGLC was a bit unfortunate for me, and I apologize
>     > for my late submission.
>     >
>     > I think this draft has many issues. It doesn't limit the number of
>     > choices, it doesn't provide enough information to implementers, it's
>     > filled with extraneous information about history and applications and
>     > much useful information is in the appendices. I don't think this
>     > draft's publication will help authors who would like to point to a
>     > reference for BLS12 and how to implement it.
>     >
>     > Sincerely,
>     > Watson Ladd
>     >
>     > --
>     > Astra mortemque praestare gradatim
>     >
>     > _______________________________________________
>     > CFRG mailing list
>     > [e-mail]
>     > https://www.irtf.org/mailman/listinfo/cfrg
>
>
>
>     --
>     Yumi Sakemi, Ph. D.
>      Infours Inc.
>
>     E-Mail: [e-mail]
>
>     _______________________________________________
>     CFRG mailing list
>     [e-mail]
>     https://www.irtf.org/mailman/listinfo/cfrg



-- 
Yumi Sakemi, Ph. D.
 Infours Inc.

E-Mail: [e-mail]