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

From: Armando Faz <[email-masked]>
Date: Sun, 1 Nov 2020 01:01:18 -0700

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 <[email-masked]> 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 <[email-masked]> 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 <[email-masked]> 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 <[email-masked]> 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.

---

From: Ian Goldberg <[email-masked]>
Date: Mon, 2 Nov 2020 15:44:56 -0500

(Sorry I'm coming in late to this.)

The draft doesn't consider settings where you need "stacks" of
pairing-friendly curves, such as for some zero-knowledge applications.
For example, MNT{4,6}-753 or the curves of
https://eprint.iacr.org/2020/351.pdf.

Was this setting considered intentionally out of scope?
-- 
Ian Goldberg
Canada Research Chair in Privacy Enhancing Technologies
Professor, Cheriton School of Computer Science
University of Waterloo

---

From: Yumi Sakemi <[email-masked]>
Date: Wed, 4 Nov 2020 17:25:06 +0900

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

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

E-Mail: [email-masked]

---

From: Yumi Sakemi <[email-masked]>
Date: Tue, 10 Nov 2020 23:43:15 +0900

Dear Prof. Ian

I'm so sorry for my late reply.
Thank you for your suggestions.

In our draft, we select the recommended pairing-friendly curves that
match two selection policies: "widely-used" and "security (the curves
are shown in peer-reviewed papers)".
If there are a lot of recommended curves in the same draft, we are
afraid that there is a possibility that the draft could confuse the
readers.
So, we limited the number of recommended curves.

I appreciate your interest in our draft!

Best regards,
Yumi

2020年11月3日(火) 5:45 Ian Goldberg <[email-masked]>:
> _______________________________________________
> CFRG mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

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