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

Yumi Sakemi <yumi.sakemi@lepidum.co.jp> Wed, 04 November 2020 08:25 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 959DE3A0D78 for <cfrg@ietfa.amsl.com>; Wed, 4 Nov 2020 00:25:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 0biFABBeH6l8 for <cfrg@ietfa.amsl.com>; Wed, 4 Nov 2020 00:25:18 -0800 (PST)
Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (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 6DB573A0D7D for <cfrg@irtf.org>; Wed, 4 Nov 2020 00:25:18 -0800 (PST)
Received: by mail-ot1-x32c.google.com with SMTP id j14so8388587ots.1 for <cfrg@irtf.org>; Wed, 04 Nov 2020 00:25:18 -0800 (PST)
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=GfoaQKG3oeh7SD7+2w8XuPdisStfAftdCmaDeG5hNHg=; b=zkRC5HxoERQf2UtxL1s2v2tAaKJM1EcLMjDZ/XxzrU2H1/7P4/egFdkN18ZisVseWH 2QXAwn8unIESLjDCeWoVBQ1BVhoJMmlnTH9KPU4MQfr5wz+Il3l5fGs/gKv1XEJY2OI6 pF1xQJnebh4ZzcK7D6Oe62m+DI+TUHAQBc0FFk+DJdVCJe63I/hayhkSYDCPb4liaXNm kMI9uU19Vr37xq29EwR2dU+/+JJn6fHh8rFBooJ+lDLkrjy284CMDpE2mHHIHV6UvlBT 2rhk3rATwX89wEmrervqKRU7ah/wT4ao0Xic456tLx/wsbketW5TnL8/zjXI1W7BmBz4 UUOQ==
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=GfoaQKG3oeh7SD7+2w8XuPdisStfAftdCmaDeG5hNHg=; b=KU2KXE6nS7YSrSDBHk0bslQHMcMOznuAJ1zWiYHYPGdbQjsh62Hf8jLchZspLQA2Ic 8V7EkTN9rt8JlIL69LfnhhwV1u4pv5+aycBYAx4Z11+n1CJnLoVyhsMdMC9vTr/6jQPs pu8K0+yAT72ZBfJoIIQux7ttPWWrkyFAO73hXMNcfbdRaqvZau2DV4bTbcGmNQh08A7r IHdBqz7yyQkX7Zoglyf9ZJChIJwZN0aF5FhCJ+DaJMIqfKnukGfZsMGJ5bmktrzED5pg Pn4FLRYQkI33ionKCHcY8pGXvdBiIFKugjz+TCHH1XKtkgSFwH4/OMps7Hudl/On+vtn HuwQ==
X-Gm-Message-State: AOAM532Stctmn7cGD2R16eH1mdv1NofFyvsy/WmwNxKYFQvTqW/HK1u9 QNRj17UwBHKE/fIxOfk/gQ2SK0IxN/gY9qOLTgsZrw==
X-Google-Smtp-Source: ABdhPJxCNNZci4GgFb9X3rdAgvxJ1tH0ZTqnLXtcdVQaZ7XORLlqG4C+1VCRaBtcGyZdduHfhFX/p/0ODBAbVaZEGeM=
X-Received: by 2002:a9d:23a6:: with SMTP id t35mr17227508otb.210.1604478317268; Wed, 04 Nov 2020 00:25:17 -0800 (PST)
MIME-Version: 1.0
References: <CABZxKYkW+gvQoz5C6op_6Wh8Od7==GHymwVWmv_4btZsAiuYAQ@mail.gmail.com>
In-Reply-To: <CABZxKYkW+gvQoz5C6op_6Wh8Od7==GHymwVWmv_4btZsAiuYAQ@mail.gmail.com>
From: Yumi Sakemi <yumi.sakemi@lepidum.co.jp>
Date: Wed, 4 Nov 2020 17:25:06 +0900
Message-ID: <CAA4D8KaCt2NGBAxEnsQYFQZ6QSOtQoqHGiqrckDDrdqaLG=aHQ@mail.gmail.com>
To: Armando Faz <armfazh@cloudflare.com>
Cc: CFRG <cfrg@irtf.org>, cfrg-chairs@ietf.org, Tetsutaro Kobayashi <tetsutaro.kobayashi.dr@hco.ntt.co.jp>, SAITO Tsunekazu <tsunekazu.saito.hg@hco.ntt.co.jp>, "Riad S. Wahby" <rsw@cs.stanford.edu>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/4gLoXRt6BLdHTvt2p1OrxNpqi-M>
Subject: Re: [CFRG] [Cfrg] I-D Action: draft-irtf-cfrg-pairing-friendly-curves-08.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: Wed, 04 Nov 2020 08:25:21 -0000

Dear Armando

Thank you for your reply!

I'm so glad we got a consensus from you.

In addition, we appreciate your comments that make our draft better.
We'll refer to them in the next version.

Best regards,
Yumi

2020年11月1日(日) 17:01 Armando Faz <armfazh@cloudflare.com>om>:
>
> Dear authors,
>
> After reviewing the pairing-friendly curves draft v08, the draft was
> improved from the previous version and is more accurate with the
> terminology used. I appreciate the authors gave careful attention to
> my previous review and I apologize for my late response. In the
> following, I give a couple of suggestions, whose purpose is to give
> feedback to the authors rather than imposing hard changes. See my
> comments interlined with previous comments.
> Best,
>
> >> Armando Faz <armfazh@cloudflare.com> Wed, 08 July 2020 12:21 UTC
> >> First, I invite the authors to reconsider the curve recommended for the 128-bit level. My suggestion is to use a BLS12 curve with a 461-bit prime replacing the BN curve with a 462-bit prime.
>
> > Yumi Sakemi <yumi.sakemi@lepidum.co.jp> Wed, 05 August 2020 02:30 UTC
> > 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.
>
> BLS parametrization is more efficient at (the current ) 128-bit level
> than BN. This efficiency comes from executing less operations, rather
> than from implementation techniques. Note that this kind of
> algorithmic improvements don't appear every other day.
>
> Both agree that moving
> BN254     -> BN462 and
> BLS12_381 -> BLS462 brings some advantages such as to reuse code bases.
> Including BLS462 as an alternative curve can be considered by the
> authors despite the selection policies.
>
> >> Armando Faz <armfazh@cloudflare.com> Thu, 09 July 2020 20:45 UTC
> >> 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.
>
> Hashing to G1 and G2 commonly uses try-and-increment method, however
> this method is not a secure one. Dragonblood is a good example of this
> vulnerability. The hash-to-curve draft warns about this security
> issue, however, the pairing draft does not include any alert about
> this threat.
>
> Currently, only BLS12_381 defines a suite for hashing to G1 and G2.
> The other curves have no suite.
> These suites can be accommodated in either the hash_to_curve draft or
> the pairing-friendly draft. Authors of both drafts must agree on where
> to define the suites.
>
> (I am more inclined to the pairing-friendly draft should instantiate
> suites according to the suite recommendation given in the
> hash_to_curve draft. This might need to move the BLS12_381 suite to
> the pairing draft, either way can work -- we can discuss this in
> another thread.)
>
> > Yumi Sakemi <yumi.sakemi@lepidum.co.jp> Wed, 05 August 2020 02:30 UTC
> > About 192bit parameters: The fact of implementation is treated as one of the evidence for "widely used", which is one of the selection policies.
>
> If no curves at 192-bit level, then section 4.3 could be removed, and
> its content moved to Section 4.
>
> --
> Armando Faz
> Cloudflare Inc.



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

E-Mail: yumi.sakemi@lepidum.co.jp