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

Armando Faz <> Tue, 05 May 2020 20:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8430B3A0A6C for <>; Tue, 5 May 2020 13:44:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id x-GdD1Rxqfkl for <>; Tue, 5 May 2020 13:44:15 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A1AE83A0A6A for <>; Tue, 5 May 2020 13:44:15 -0700 (PDT)
Received: by with SMTP id u6so21877ljl.6 for <>; Tue, 05 May 2020 13:44:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:from:date:message-id:subject:to; bh=yaXOhLMXwWjo1e6B0ZhgB5+BnSBu5whFGcHnScZ8YHE=; b=t3+zggrJuWPJw+yevHznAtfp3C8/HXDYghQVa76xjdwBEVj61Y2zqpiQAxZ7WG2USW dl8LYA7pVxpLZ1YaTDP+VODm931+LAgSC2Xzd5MwEAPil6bOwvVt0v3kaE5XHHy32Jih sGLTqE/R+6WErrybntRq1JSyls5aHEoMctx4k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=yaXOhLMXwWjo1e6B0ZhgB5+BnSBu5whFGcHnScZ8YHE=; b=gjr1rvY66pJ8lCJjdWUkUAEN21IhNufGhK4KGcnUrNoktyGj+VG5Qr3uAKGlmUH8kN /rQjxa67KdHRl3ag5v5AUBERerQLYMdWKddL2d0MA7X1ok/mhiPBZtHzhO8Yty+XKjYy XNfGvA3jaKBjqH4NouYHmOECpV37CFbRS7ZE3DAEMwnayRyZJNEbTm7o6o3jWOwdErqN KCM2fQh3eyztTgcfjVSg7JL89V419AswfBBwDsEXNwdaQ4WFDjntaZiku0Q74a7bFxB7 MFXfibkMxteTd7UJkQ+3LcDSYm8ToLUwj9pOJtt/iJ7LMNUOUMsZazOBFNXkQIboirzM P5yw==
X-Gm-Message-State: AGi0PuZ+Z6kTypZ3ehi6bckLHMULfOpHZJ2BuMLpKjSeSK8DHOpReJLW xyDn4AhS8rm7HbDzeD4r9Y7rGuBNI4xXzPJBHbfgTHFrTKc=
X-Google-Smtp-Source: APiQypKN0DVY1JuDxbbL2HsVGmEOYNir4oSUHP+22GoopLu+EjrbI1OGxnNnjTLR6K4L93g2ajTAOiluxWgAHeDVu3k=
X-Received: by 2002:a05:651c:549:: with SMTP id q9mr2973034ljp.236.1588711453159; Tue, 05 May 2020 13:44:13 -0700 (PDT)
MIME-Version: 1.0
From: Armando Faz <>
Date: Tue, 5 May 2020 13:44:02 -0700
Message-ID: <>
Content-Type: multipart/alternative; boundary="000000000000d1105a05a4ecb50a"
Archived-At: <>
Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-pairing-friendly-curves-04.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 05 May 2020 20:44:18 -0000

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 ( I think some comments should be added
regarding this notion.

Have you considered the use of other models such as Hessian curves ( ? 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.)


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.