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

[Armando Faz <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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.