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

[Yumi Sakemi <[e-mail]>]

Dear Armand

Thank you very much for your comments on our draft.
I am so sorry for my late reply.
I had a discussion with the co-authors.

According to the four comments you have sent, we answer as follows.

1. Concerns about future improvements of attacks
As you pointed out, the attack may be improved in the future.
It's a very important point of view, so I'm so glad to receive your comments.
When an attack that has a great impact on security, such as Kim's
Attack announced in 2016, was proposed,
we should do a security evaluation by a research approach, and based
on the results, we should  re-select appropriate curves in IETF.

2. About subgroup security
Thank you for pointing out.
The paper [BD18], which we refer to as a basis for security level,
describes subgroup security.
However, our draft does not describe sub-group security, so we should
add to our draft.
It will be reflected in a future version.
As a result, the concept of sub-group security influences to the
candidate curves,
so we will also add countermeasures to the security consideration.

[BD18] Barbulescu, R. and S. Duquesne, "Updating Key Size Estimations
for Pairings"
       https://eprint.iacr.org/2017/334

3. About other types of curves
As you pointed out, we are also interested in other types of curves,
so we have considered them so far.
However, in our selection policy, it is important that multiple
implementations exist,
so we chose the BN and BLS curves this time.

4. About details algorithms using isomorphism
We understand that there are improvements using isomorphism.
However, because there are two concerns, we describe the most basic
algorithm in our draft.
One is that isomorphism techniques may be related to IPR, so our draft
does not show the detail algorithm.
The result of pairing does not change depending on whether or not
isomorphism technique is used,
so the implementer can confirm the correctness of the implementation
by checking whether the correct value, which equals the test vector,
is output.

The other is that the various improvements can be applied depending on
types of curves,
so in order not to reduce the flexibility of the implementer, we avoid
deciding the detailed algorithm.


Finally, I also appreciate your comments on the editorial parts.
Thank you for reading our draft !

Best regards,
Yumi

2020年5月6日(水) 5:44 Armando Faz <armfazh=[e-mail]>:
>
> 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 (https://eprint.iacr.org/2015/247)? I think some comments should be added regarding this notion.
>
> Have you considered the use of other models such as Hessian curves (https://eprint.iacr.org/2018/1026). ? 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.)
>
>
> Editorial:
>
> 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.
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg



-- 
Yumi Sakemi
Lepidum Co. Ltd.
E-Mail: [e-mail]