Re: [Cfrg] I-D Action: draft-irtf-cfrg-pairing-friendly-curves-04.txt

Yumi Sakemi <yumi.sakemi@lepidum.co.jp> Mon, 18 May 2020 14:11 UTC

Return-Path: <yumi.sakemi@lepidum.co.jp>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7AC3A0045 for <cfrg@ietfa.amsl.com>; Mon, 18 May 2020 07:11:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lepidum-co-jp.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-CZ9pBMIAOK for <cfrg@ietfa.amsl.com>; Mon, 18 May 2020 07:11:22 -0700 (PDT)
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8F733A003E for <cfrg@irtf.org>; Mon, 18 May 2020 07:11:21 -0700 (PDT)
Received: by mail-lj1-x233.google.com with SMTP id z18so1798560lji.12 for <cfrg@irtf.org>; Mon, 18 May 2020 07:11:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lepidum-co-jp.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=QPQOSvQwHAm79AnIwU8klblqMOyl2uAQ5KEJY2uzq0g=; b=i4HSA30MlL/nlTLIEGlx0P02o4xSLJMjh8UCJQ/T3lf3SOTj0cGPeLsp7J7noestJW gaG/siYNLjI5FGWK9+UJ/Y1iNHecmNLzwOzgrzw0cKhgFLCTRCZRQYIzaEX/Gr2qbD6D 5fEWiE+f7yYtGeD7mY8CJdXx3fQWnNlKTz/BockIMJT/7PEsDq4m6/NYyX3dm3nai/bB VKCXtaA5wyuaihS5v7n5nR/Cqv/a289yzcPIsSMmVFVDeCvPRpjMepMilNmZokAzEkj5 2n+sVD6nOS60AJiF3oN95Z2WxDreJTHZM3Gi/7nm8S/2rpxauNbtFh3fY8Oy4oIrk9ri 7ZuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=QPQOSvQwHAm79AnIwU8klblqMOyl2uAQ5KEJY2uzq0g=; b=aTxVT5jCDc8BRP4cL5ybL+HmrxrH0ZMH1HLbCrRDGxKYe3c8NUEBtGD1Y/h6Aj8SlO sv4dfiF1J6ZXgWfJrcQC7/xmX6OJu2/ooP4aMYePvuFyqBNQxkXHC0c2FW+mmb1OlIU6 f99ooa1vCP68D/wijUs6RPCJYUWcgwzYqU7OR0Bs62+utopB0k4dbEGcIRtzy+MNivfw wPtRToBeICdmhm3vtvR0evkQOUQZGiMtiQWU4pnhJk8ps/ZLRcoSLCq13SuiKh1mc0hl oWEjMdYZWKh8f6OJtv0Pt0aMpGJBSttf0EKp0pCmZeAahpwstkNa4cRZxTQZ3YoiKr0M IAPQ==
X-Gm-Message-State: AOAM533b9cSGEek7iNAkjlkU3TLC6rYd8YMWVwqgf6IKxke0awsdBmsA eJe01bZpcPNYmpZkqLHxFC7bW+ebWsSdhZ1SZT1J6g==
X-Google-Smtp-Source: ABdhPJzO4P+px/adrgjO+SSLj54Ua7bKUOAOEUf7b4PTcJWHIQFFYZjzL9kNwf0UVyIRCAcro4yDOeHfcbfCfZwnJZ0=
X-Received: by 2002:a2e:8997:: with SMTP id c23mr5614154lji.22.1589811079339; Mon, 18 May 2020 07:11:19 -0700 (PDT)
MIME-Version: 1.0
References: <CABZxKYm5PcZg4sV7hcgRvp5ecpPXROMw1JcgkAXeNRur=PzKOA@mail.gmail.com>
In-Reply-To: <CABZxKYm5PcZg4sV7hcgRvp5ecpPXROMw1JcgkAXeNRur=PzKOA@mail.gmail.com>
From: Yumi Sakemi <yumi.sakemi@lepidum.co.jp>
Date: Mon, 18 May 2020 23:11:08 +0900
Message-ID: <CAA4D8KbQRWRBmuED-Giu1NN_CJ=nLdtUuWej7VLicAvYawu5WA@mail.gmail.com>
To: Armando Faz <armfazh=40cloudflare.com@dmarc.ietf.org>
Cc: cfrg@irtf.org, Tetsutaro Kobayashi <tetsutaro.kobayashi.dr@hco.ntt.co.jp>, SAITO Tsunekazu <tsunekazu.saito.hg@hco.ntt.co.jp>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/NoPUYPFquwz3GEY67vVgdfwedsI>
Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-pairing-friendly-curves-04.txt
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 May 2020 14:11:24 -0000

Dear Armand

Thank you very much for your comments on our draft.
I am so sorry for my late reply.
I had a discussion with the co-authors.

According to the four comments you have sent, we answer as follows.

1. Concerns about future improvements of attacks
As you pointed out, the attack may be improved in the future.
It's a very important point of view, so I'm so glad to receive your comments.
When an attack that has a great impact on security, such as Kim's
Attack announced in 2016, was proposed,
we should do a security evaluation by a research approach, and based
on the results, we should  re-select appropriate curves in IETF.

2. About subgroup security
Thank you for pointing out.
The paper [BD18], which we refer to as a basis for security level,
describes subgroup security.
However, our draft does not describe sub-group security, so we should
add to our draft.
It will be reflected in a future version.
As a result, the concept of sub-group security influences to the
candidate curves,
so we will also add countermeasures to the security consideration.

[BD18] Barbulescu, R. and S. Duquesne, "Updating Key Size Estimations
for Pairings"
       https://eprint.iacr.org/2017/334

3. About other types of curves
As you pointed out, we are also interested in other types of curves,
so we have considered them so far.
However, in our selection policy, it is important that multiple
implementations exist,
so we chose the BN and BLS curves this time.

4. About details algorithms using isomorphism
We understand that there are improvements using isomorphism.
However, because there are two concerns, we describe the most basic
algorithm in our draft.
One is that isomorphism techniques may be related to IPR, so our draft
does not show the detail algorithm.
The result of pairing does not change depending on whether or not
isomorphism technique is used,
so the implementer can confirm the correctness of the implementation
by checking whether the correct value, which equals the test vector,
is output.

The other is that the various improvements can be applied depending on
types of curves,
so in order not to reduce the flexibility of the implementer, we avoid
deciding the detailed algorithm.


Finally, I also appreciate your comments on the editorial parts.
Thank you for reading our draft !

Best regards,
Yumi

2020年5月6日(水) 5:44 Armando Faz <armfazh=40cloudflare.com@dmarc.ietf.org>rg>:
>
> Hi, I would like to give some feedback to the pairing-friendly-curves draft-v04. Hope this helps to improve the document.
>
> I am concerned about the security levels currently claimed. Before 2016, everybody agreed that BN256 provided 128-bit security, after the improvements on NFS the security level was reduced. So, what would happen in the future when another improvement is discovered? Is there some escalation plan for anticipating this event?
>
> As there isn't a recommendation of curves at 192-bit level, so at the point when moving from 128- to the 256-bit level, the change would be dramatic. I think some curves should be recommended, even though they are not widely used currently.
>
> Does the curves proposed satisfy the notion of subgroup security (https://eprint.iacr.org/2015/247)? I think some comments should be added regarding this notion.
>
> Have you considered the use of other models such as Hessian curves (https://eprint.iacr.org/2018/1026). ? They are interesting since they provide fast pairings for odd embedding degrees.
>
> What is the isomorphism used in each instance?
> ## When implementing the line function, implementers should consider the isomorphism of E and its twisted curve E' so that one can reduce the computational cost of operations in G_2.  We note that Line_function does not consider such isomorphism
>
> The description of pairing computation doesn't describe the outcome of the special cases, e.g. when points do not belong to G1 or G2, or when the input points are the identity. (I consider this is important for implementers not familiar with pairings.)
>
>
> Editorial:
>
> Soluti\ons -> Solutions
>
> Better to use k for denoting a scalar, in
> ## Similarly, we can define 2P = P + P and a scalar multiplication S = [k]P for a positive integer k can be defined as an (k-1)-time addition of P.
>
> T belongs to E'
> ## Similarly, for any S in G_1, e(S, T) = 1 if and only if T = O_E'
>
> reducedto -> reduced to
>
> In the description of ate pairing computation, there is an inconsistency between the number of inputs of the Line_function.
>
> --
> Armando Faz
> Cloudflare Inc.
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg



-- 
Yumi Sakemi
Lepidum Co. Ltd.
E-Mail: yumi.sakemi@lepidum.co.jp