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

Armando Faz <armfazh@cloudflare.com> Sun, 01 November 2020 08:01 UTC

Return-Path: <armfazh@cloudflare.com>
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 3A6BD3A0BFF for <cfrg@ietfa.amsl.com>; Sun, 1 Nov 2020 01:01:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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 (1024-bit key) header.d=cloudflare.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 8lM6nW-YJKIb for <cfrg@ietfa.amsl.com>; Sun, 1 Nov 2020 01:01:32 -0700 (PDT)
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 AE85C3A0C11 for <cfrg@irtf.org>; Sun, 1 Nov 2020 01:01:31 -0700 (PDT)
Received: by mail-lf1-x133.google.com with SMTP id j30so13360205lfp.4 for <cfrg@irtf.org>; Sun, 01 Nov 2020 01:01:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=9YWbfdTSeb927CgQ+DwZtxmOyC1yYIORKWwFu/EGEe8=; b=XtfQyNRq6CWbcXglHQ2jjMS6jLQH3UYSwfar9jNwwnJq0moR6gWK3TS3qo28NwFKdI krEeE5Zbc42Lxq4U/Q5wozxo3fxwMjYNcdmRohH3c4b8Ag1duuQ5lcZrvBdR9NyT/Yj8 IIbEwo5yWwWWSVZtMGVc4ec2y3LP8OENGJ26E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=9YWbfdTSeb927CgQ+DwZtxmOyC1yYIORKWwFu/EGEe8=; b=pS7xiUbC2oF1pZ3RVdApMx78pklrq1ArOyQXBlMIffcd2YkcGkuN0G5STgb1VTHlW4 wuBPHhA0PPqFSBX/qRNpExJJfTdsmiYJEbXJqEoTL6G0AjfZ3sYmT9FOglE4g0Sf8hgy hi4bOI0eQk285Qny76g1QywY1T/lHc7/RQzKWz9ZTbaXo3RtICjR/n1HXyS9uBDva5I7 F7GHw8dBE02hpcCmVlCLSBSKLhX7qFgsanNBgq/0/PGwNNtgxluN+JMvxnB3BXMnYZsP yMSJ0tLQJzYEbfMLfglau92U1iNlChzJrpLiILUbu3lZQ29D4T0IAL+uA+YDy7UxWGto vPhA==
X-Gm-Message-State: AOAM533iyeZ7d3w/ZkDIb5j3PZjSjg311yHmxw4VROADtqpoAIwhyswh gUikH0zrEzOFC+/K7I/ml/0AtvvavU/p74vGB2lJLmbA0C57+X+G
X-Google-Smtp-Source: ABdhPJylYaEezkcFjj5+l631krRXXD/2W6QFcvkx40GVBvdpeEoCbF2DwMo84+VFhFADgbTG1izPRl0CFg0+ENLDsQw=
X-Received: by 2002:a19:e305:: with SMTP id a5mr3644305lfh.549.1604217689392; Sun, 01 Nov 2020 01:01:29 -0700 (PDT)
MIME-Version: 1.0
From: Armando Faz <armfazh@cloudflare.com>
Date: Sun, 1 Nov 2020 01:01:18 -0700
Message-ID: <CABZxKYkW+gvQoz5C6op_6Wh8Od7==GHymwVWmv_4btZsAiuYAQ@mail.gmail.com>
To: cfrg@irtf.org, yumi.sakemi@lepidum.co.jp
Cc: cfrg-chairs@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/sIzv6XLNuL8VHor5voO1ybO__oI>
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: Sun, 01 Nov 2020 08:01:34 -0000

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.