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

["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