Subject: [Cfrg] Fwd: I-D Action: draft-yonezawa-pairing-friendly-curves-01.txt

From: Shoko YONEZAWA <[email-masked]>
Date: Wed, 13 Mar 2019 19:33:15 +0900

Hi there,

Thank you for your comments to our pairing-friendly curve draft.
We submitted a new version.

According to Kenny's comments,
we added the following description to the new version.

- Pseudo-codes for pairing computation
- Example parameters and test vectors of each curve

We now published our working draft on GitHub,
together with the BLS signature group.
Please feel free to submit issues. Your comments are really appreciated.

https://github.com/pairingwg/pfc_standard/

Best,
Shoko

-------- Forwarded Message --------
Subject: I-D Action: draft-yonezawa-pairing-friendly-curves-01.txt
Date: Mon, 11 Mar 2019 08:34:48 -0700
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

         Title           : Pairing-Friendly Curves
         Authors         : Shoko Yonezawa
                           Sakae Chikara
                           Tetsutaro Kobayashi
                           Tsunekazu Saito
	Filename        : draft-yonezawa-pairing-friendly-curves-01.txt
	Pages           : 28
	Date            : 2019-03-11

Abstract:
    This memo introduces pairing-friendly curves used for constructing
    pairing-based cryptography.  It describes recommended parameters for
    each security level and recent implementations of pairing-friendly
    curves.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-yonezawa-pairing-friendly-curves/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-yonezawa-pairing-friendly-curves-01
https://datatracker.ietf.org/doc/html/draft-yonezawa-pairing-friendly-curves-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-yonezawa-pairing-friendly-curves-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Michael Scott <[email-masked]>
Date: Thu, 14 Mar 2019 15:21:58 +0000

Hello,

I greatly welcome this proposal, and would not want to slow its progress in
any way. It is long overdue that pairing-friendly curves be standardized,
before unsuitable de-facto standards emerge, which may not be ideal, but
which may nevertheless become widely deployed.

However I make the following observations about the particular curves
suggested.

The suggested curves do not appear to meet the requirement for subgroup
security which is indicated as being a desirable property in section 3.1 -
“One has to choose parameters so that the cofactors of G_1, G_2 and G_T
contain no prime factors smaller than |G_1|, |G_2| and |G_T|”.

The case could be made that subgroup security is not so important, but if
so the text in 3.1 should be modified to reflect this point of view.

The curve BN462 is not sub-group secure, as in G_T (p^4-p^2+1) /r has small
factors of 2953, 5749 and 151639045476553 (amongst others). I didn’t check
G_2.

The curve BLS381 has the same problem, as (p^4-p^2+1) /r has small factor
of 4513, 584529700689659162521 and more. Again I didn’t check G_2

The curve BLS48-581 has the same problem, as (p^4-p^2+1) /r has a small
factor of 76369, and probably others. Again I didn’t check for G_2

The draft does point out that for BLS curves, when hashing to a point in
G_1, multiplication by a small co-factor h>1 will always be necessary.

In my opinion sub-group security in G_T is particularly important if it is
desirable to offload the pairing calculation to an untrusted server, and so
it is a feature I would consider useful in a standard curve. In our
experience finding such curves is relatively easy (although finding curves
that are sub-group secure in both G_2 and G_T is more problematical).

Another point – the BLS381 curve was chosen for a very particular (albeit
important) application where it is a requirement that r-1 has a factor of
2^m for a large value of m. Curves chosen with application-specific
benefits should I suggest be considered carefully if proposed as more
general purpose standards. Note that this particular application
disadvantages BN curves, as due to the form of its formula for r, this
particular condition is much harder to achieve.

Mike

On Wed, Mar 13, 2019 at 10:33 AM Shoko YONEZAWA <[email-masked]>
wrote:

> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

---

From: Michael Scott <[email-masked]>
Date: Thu, 14 Mar 2019 18:52:38 +0000

Another point..

For the BLS curves, the cofactor h in G_1 is calculated here as
((t-1)^2)/3, and this will work fine as a co-factor, where a random point
on the curve over the base field can be multiplied by this co-factor to
create a point of order r in G_1. But this co-factor is unnecessarily large.

The same can be achieved by using (t-1) as a co-factor, due to the
structure of pairing friendly fields. This will be twice as fast.

Mike

However to

On Thu, Mar 14, 2019 at 3:21 PM Michael Scott <[email-masked]> wrote:

> Hello,
>
> I greatly welcome this proposal, and would not want to slow its progress
> in any way. It is long overdue that pairing-friendly curves be
> standardized, before unsuitable de-facto standards emerge, which may not be
> ideal, but which may nevertheless become widely deployed.
>
> The curve BN462 is not sub-group secure, as in G_T (p^4-p^2+1) /r has
> small factors of 2953, 5749 and 151639045476553 (amongst others). I didn’t
> check G_2.
>

---

From: David Wong <[email-masked]>
Date: Thu, 14 Mar 2019 17:56:46 -0700

Another point is that BLS12-381 is estimated at 120 bits of security at most. See page 8 of https://www.nccgroup.trust/us/our-research/zcash-overwinter-consensus-and-sapling-cryptography-review/ <https://www.nccgroup.trust/us/our-research/zcash-overwinter-consensus-and-sapling-cryptography-review/>

David

> On Mar 14, 2019, at 11:52 AM, Michael Scott <[email-masked]> wrote:
> 
> Another point..
> 
> For the BLS curves, the cofactor h in G_1 is calculated here as ((t-1)^2)/3, and this will work fine as a co-factor, where a random point on the curve over the base field can be multiplied by this co-factor to create a point of order r in G_1. But this co-factor is unnecessarily large.
> 
> The same can be achieved by using (t-1) as a co-factor, due to the structure of pairing friendly fields. This will be twice as fast. 
> 
> 
> Mike
> 
> 
> However to 
> 
> On Thu, Mar 14, 2019 at 3:21 PM Michael Scott <[email-masked] <mailto:[email-masked]>> wrote:
> Hello,
> I greatly welcome this proposal, and would not want to slow its progress in any way. It is long overdue that pairing-friendly curves be standardized, before unsuitable de-facto standards emerge, which may not be ideal, but which may nevertheless become widely deployed.
> However I make the following observations about the particular curves suggested.
> The suggested curves do not appear to meet the requirement for subgroup security which is indicated as being a desirable property in section 3.1 - “One has to choose parameters so that the cofactors of G_1, G_2 and G_T contain no prime factors smaller than |G_1|, |G_2| and |G_T|”.
> The case could be made that subgroup security is not so important, but if so the text in 3.1 should be modified to reflect this point of view.
> The curve BN462 is not sub-group secure, as in G_T (p^4-p^2+1) /r has small factors of 2953, 5749 and 151639045476553 (amongst others). I didn’t check G_2.
> The curve BLS381 has the same problem, as (p^4-p^2+1) /r has small factor of 4513, 584529700689659162521 and more. Again I didn’t check G_2
> The curve BLS48-581 has the same problem, as (p^4-p^2+1) /r has a small factor of 76369, and probably others. Again I didn’t check for G_2
> The draft does point out that for BLS curves, when hashing to a point in G_1, multiplication by a small co-factor h>1 will always be necessary.
> In my opinion sub-group security in G_T is particularly important if it is desirable to offload the pairing calculation to an untrusted server, and so it is a feature I would consider useful in a standard curve. In our experience finding such curves is relatively easy (although finding curves that are sub-group secure in both G_2 and G_T is more problematical).
> Another point – the BLS381 curve was chosen for a very particular (albeit important) application where it is a requirement that r-1 has a factor of 2^m for a large value of m. Curves chosen with application-specific benefits should I suggest be considered carefully if proposed as more general purpose standards. Note that this particular application disadvantages BN curves, as due to the form of its formula for r, this particular condition is much harder to achieve.
> 
> Mike
> 
> On Wed, Mar 13, 2019 at 10:33 AM Shoko YONEZAWA <[email-masked] <mailto:[email-masked]>> wrote:
> Hi there,
> 
> https://github.com/pairingwg/pfc_standard/ <https://github.com/pairingwg/pfc_standard/>
> 
> Best,
> Shoko
> 
> From: [email-masked] <mailto:[email-masked]>
> Reply-To: [email-masked] <mailto:[email-masked]>
> To: [email-masked] <mailto:[email-masked]>
> 
> 
> https://datatracker.ietf.org/doc/draft-yonezawa-pairing-friendly-curves/ <https://datatracker.ietf.org/doc/draft-yonezawa-pairing-friendly-curves/>
> 
> https://tools.ietf.org/html/draft-yonezawa-pairing-friendly-curves-01 <https://tools.ietf.org/html/draft-yonezawa-pairing-friendly-curves-01>
> https://datatracker.ietf.org/doc/html/draft-yonezawa-pairing-friendly-curves-01 <https://datatracker.ietf.org/doc/html/draft-yonezawa-pairing-friendly-curves-01>
> 
> https://www.ietf.org/rfcdiff?url2=draft-yonezawa-pairing-friendly-curves-01 <https://www.ietf.org/rfcdiff?url2=draft-yonezawa-pairing-friendly-curves-01>
> 
> 
> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> 
> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/i-d-announce <https://www.ietf.org/mailman/listinfo/i-d-announce>
> Internet-Draft directories: http://www.ietf.org/shadow.html <http://www.ietf.org/shadow.html>
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.irtf.org/mailman/listinfo/cfrg <https://www.irtf.org/mailman/listinfo/cfrg>

---

From: Shoko YONEZAWA <[email-masked]>
Date: Tue, 19 Mar 2019 12:39:06 +0900

Dear Mike,

Thank you very much for your comments.

> so the text in 3.1 should be modified to reflect this point of view.

As you pointed out, we found that our suggested curves are not 
subgroup-secure.
For standardization, we focus on the existing implementations as well as 
sufficient security.
We think it impractical to choose a completely new parameter and 
implement it from now.
Therefore, we would like to recommend the current parameters we 
described in the draft with modifying our description of subgroup security.

We are keeping watching the research activity and ready to change 
parameters if a critical attack for pairing-friendly curves which don't 
meet subgroup security is found.

> particular condition is much harder to achieve.

We guess that BLS12-381 is chosen for the efficient computation of their 
zero-knowledge proof. Nonetheless, we think BLS12-381 has sufficient 
performance for general purpose.

Best regards,
Shoko

-- 
Shoko YONEZAWA
Lepidum Co. Ltd.
[email-masked]
TEL: +81-3-6276-5103

---

From: Shoko YONEZAWA <[email-masked]>
Date: Tue, 19 Mar 2019 13:23:09 +0900

Dear David,

Thank you for sharing this report.
This is very valuable and we will add the security evaluation of 
BLS12-381 to the next version.

In our draft, we described BLS12-381 as an "optimistic" parameter for 
128 bits of security.
Some people might evaluate 120 bits of security as insufficient,
but we guess 120 bits of security is acceptable.

It is true that BLS12-381 is adopted to several applications and libraries.
As we stated in our draft, we would like to choose parameters by 
considering efficiency and global acceptance as well as security.

Best regards,
Shoko

-- 
Shoko YONEZAWA
Lepidum Co. Ltd.
[email-masked]
TEL: +81-3-6276-5103

---

From: Michael Scott <[email-masked]>
Date: Wed, 20 Mar 2019 15:48:40 +0000

A couple of further observations..

It would be helpful for implementors to know if the curves support an
M-Type or D-Type twist.

BLS381 and BN462 are both M-Type. BLS48_581 is D-Type.

Also I think a standard should also include a generator point for G2 for
interoperability, as well as for G1. For example an implementation of BLS
short signature probably requires a generator in G2.

Mike

On Tue, Mar 19, 2019 at 3:39 AM Shoko YONEZAWA <[email-masked]>
wrote:

> >> On Wed, Mar 13, 2019 at 10:33 AM Shoko YONEZAWA <[email-masked]
> >
> >> wrote:
> >>
> >>> Hi there,
> >>>
> >>>          Filename        :
> draft-yonezawa-pairing-friendly-curves-01.txt
> >>>          Pages           : 28
> >>>          Date            : 2019-03-11
> >>>
> >>> Abstract:

---

From: Shoko YONEZAWA <[email-masked]>
Date: Thu, 28 Mar 2019 16:26:58 +0900

Hi Mike,

Thank you again for the feedback.

 > BLS381 and BN462 are both M-Type. BLS48_581 is D-Type.

As the information for implementers,
we add the description of M-type or D-type for each curve.

 > short signature probably requires a generator in G2.

The generator point for G2 is described as a base point G' = (x', y')
in our draft.
We revise the description for clarification.

Best,
Shoko

-- 
Shoko YONEZAWA
Lepidum Co. Ltd.
[email-masked]
TEL: +81-3-6276-5103

---

From: Michael Scott <[email-masked]>
Date: Thu, 28 Mar 2019 11:11:00 +0000

OK. However for the BL381 curve for example the G2 generator point does not
appear to be the same as the one given here...

https://github.com/zkcrypto/pairing/tree/master/src/bls12_381

Also it would help if the individual components of x' and  y' were
highlighted. For example if x'=a'u+b' it would be useful to know were a'
ends and b' begins.

 Also as in the above link it would I think be good practice to state
exactly how the values for G1 and G2 were arrived at.

Mike

On Thu, Mar 28, 2019 at 7:27 AM Shoko YONEZAWA <[email-masked]>
wrote:

> >>>> In my opinion sub-group security in G_T is particularly important if
> it
> >> is
> >>>>>       pairing-based cryptography.  It describes recommended
> parameters
> >> for

---

From: Marek Jankowski <[email-masked]>
Date: Thu, 28 Mar 2019 03:45:19 +0100

Dear Shoko,

I am supportive of this work. Pairings give rise to useful cryptographic
primitives and so should be well standardized.
Please find below some minor comments and questions about the I-D.

Section 1.1 - "The cryptographic algorithms [...] is widely used" should be
"The cryptographic algorithms [...] are widely used", and a bit later "a
variant [...] is attracted the attention" should be
"a variant [...] has attracted the attention".

In the last sentence of the section, "several applications [...] is now in
practical use." should be replaced with  "several applications [...] are
now in practical use."

Section 2.1 - as there are several variants for elliptic curves, it may be
kind to remind the reader that the specified equation is the Weierstrass
form.
Also, A and B satisfy the discriminant inequality (and not "satisfies").
"the line that intersects P and Q" should be "the line that passes through
P and Q".

I personally feel it is redundant to thoroughly explain the addition law of
the EC group, but if such care is taken, then I think it is a good idea to
also specify doubling, i.e. P+P.

While defining the BN and BLS curves (Sections 2.3, 2.4), formulae are
given for p and r as a function of t, and it says that t should be chosen
"well". What makes a choice
of t good? Is it sufficient to require p and r to be prime?

In the Appendix, it would be good practice to specifically mention that for
most uses, calculations should be done in constant time.

In addition, I found it difficult to follow the properties required from s
and s_i (apart from sum s_i * 2^i = s). Do different choices give rise to
different pairings?
Or is it an efficiency issue?

Thank you,

Marek.

On Thu, Mar 28, 2019 at 12:12 PM Michael Scott <[email-masked]>
wrote:

> OK. However for the BL381 curve for example the G2 generator point does
> not appear to be the same as the one given here...
>
>> >>>> The case could be made that subgroup security is not so important,
>> but
>> >> if
>> >>>> important) application where it is a requirement that r-1 has a
>> factor
>> >> of
>> https://datatracker..ietf.org/doc/draft-yonezawa-pairing-friendly-curves/
>> <https://datatracker.ietf.org/doc/draft-yonezawa-pairing-friendly-curves/>
>> >>>>>
>> >>>>> until the htmlized version and diff are available at
>> tools..ietf.org <http://tools.ietf.org>.
>> >>>>>
>> <http://www.ietf..org/shadow.html>

---

From: Shoko YONEZAWA <[email-masked]>
Date: Fri, 29 Mar 2019 19:02:52 +0900

Hi Mike,

This difference is probably caused by representation of an extension field.
We encoded the generator G' = (x', y') where x' = a'*u + b' and y' = 
c'*u + d' by

x' : a'*p + b' (in Z) and
y' : c'*p + d' (in Z),

whereas zkcrypto encoded it like

x' : a' || b' and
y' : c' || d'.

We followed the convention shown in IEEE 1363a-2004.

As you suggested, it is helpful to describe a',b',c',d' as well as x', y'.
We add these value in the next version.

Thank you again,
Shoko

On 2019/03/28 20:11, Michael Scott wrote:
>>>>> contain no prime factors smaller than |G_1|, |G_2| and |G_T|”..
>>>>>
>>>>>> that are sub-group secure in both G_2 and G_T is more problematical)..
>>>>>>
>>>>>>> until the htmlized version and diff are available at tools.ietf.org..
>>>>>>>

-- 
Shoko YONEZAWA
Lepidum Co. Ltd.
[email-masked]
TEL: +81-3-6276-5103

---

From: Shoko YONEZAWA <[email-masked]>
Date: Fri, 29 Mar 2019 19:54:17 +0900

Dear Marek,

thank you very much for your support of our work
and definitely careful feedback.

I've added your comments to Issues of our GitHub repository.

 > Or is it an efficiency issue?

A parameter t is chosen so that,
when t (or 6*t+2 in BN curve) is represented
by the sum of s_i * 2^i (i = 0, ... , L and s_i in {-1,0,1}),
as many s_i as possible becomes 0.

This enables the efficient computation of pairing.
You can see the pseudo codes in Appendix A and find that Line_function 
can be reduced when s_i = 0.

Pairing is the same in the different choices of s_i.
They are chosen simply for efficiency.

Best,
Shoko

On 2019/03/28 11:45, Marek Jankowski wrote:
>>> but if
>>> factor of

-- 
Shoko YONEZAWA
Lepidum Co. Ltd.
[email-masked]
TEL: +81-3-6276-5103

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Thu, 28 Mar 2019 18:45:58 +0000

Naïve question: how is this approach supposed to weather in post-quantum world? 

From: Cfrg <[email-masked]> on behalf of Marek Jankowski <[email-masked]>
Date: Thursday, March 28, 2019 at 07:56
To: "[email-masked]" <[email-masked]>
Cc: CFRG <[email-masked]>
Subject: Re: [Cfrg] Fwd: I-D Action: draft-yonezawa-pairing-friendly-curves-01.txt

Dear Shoko,

I am supportive of this work. Pairings give rise to useful cryptographic primitives and so should be well standardized.

Section 1.1 - "The cryptographic algorithms [...] is widely used" should be "The cryptographic algorithms [...] are widely used", and a bit later "a variant [...] is attracted the attention" should be 

"a variant [...] has attracted the attention"..

In the last sentence of the section, "several applications [...] is now in practical use." should be replaced with  "several applications [...] are now in practical use."

Section 2.1 - as there are several variants for elliptic curves, it may be kind to remind the reader that the specified equation is the Weierstrass form.

Also, A and B satisfy the discriminant inequality (and not "satisfies"). "the line that intersects P and Q" should be "the line that passes through P and Q".

I personally feel it is redundant to thoroughly explain the addition law of the EC group, but if such care is taken, then I think it is a good idea to also specify doubling, i.e. P+P.

While defining the BN and BLS curves (Sections 2.3, 2.4), formulae are given for p and r as a function of t, and it says that t should be chosen "well". What makes a choice

In the Appendix, it would be good practice to specifically mention that for most uses, calculations should be done in constant time.

In addition, I found it difficult to follow the properties required from s and s_i (apart from sum s_i * 2^i = s). Do different choices give rise to different pairings?

Thank you,

Marek.

On Thu, Mar 28, 2019 at 12:12 PM Michael Scott <[email-masked]> wrote:

OK. However for the BL381 curve for example the G2 generator point does not appear to be the same as the one given here... 

Also it would help if the individual components of x' and  y' were highlighted. For example if x'=a'u+b' it would be useful to know were a' ends and b' begins. 

 Also as in the above link it would I think be good practice to state exactly how the values for G1 and G2 were arrived at.

Mike

On Thu, Mar 28, 2019 at 7:27 AM Shoko YONEZAWA <[email-masked]> wrote:

Hi Mike,

Best,
Shoko

On 2019/03/21 0:48, Michael Scott wrote:
>> https://datatracker...ietf.org/doc/draft-yonezawa-pairing-friendly-curves/
>>>>>
>>>>> until the htmlized version and diff are available at tools...ietf.org.
>>>>>

-- 
Shoko YONEZAWA
Lepidum Co. Ltd.
[email-masked]
TEL: +81-3-6276-5103

---

From: "Paterson Kenneth" <[email-masked]>
Date: Fri, 29 Mar 2019 15:59:24 +0000

Hi Uri,

It doesn’t but we did already discuss that, and good arguments were put forth for continuing the work despite this. (See the mail archive, I guess.)

Cheers

Kenny

From: Cfrg <[email-masked]> on behalf of "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Friday, 29 March 2019 at 15:54
To: Marek Jankowski <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Cfrg] Fwd: I-D Action: draft-yonezawa-pairing-friendly-curves-01.txt

Dear Shoko,

Section 1.1 - "The cryptographic algorithms [...] is widely used" should be "The cryptographic algorithms [....] are widely used", and a bit later "a variant [...] is attracted the attention" should be
"a variant [...] has attracted the attention"..

Thank you,

Marek.

On Thu, Mar 28, 2019 at 12:12 PM Michael Scott <[email-masked]<mailto:[email-masked]>> wrote:
OK. However for the BL381 curve for example the G2 generator point does not appear to be the same as the one given here...

Mike

On Thu, Mar 28, 2019 at 7:27 AM Shoko YONEZAWA <[email-masked]<mailto:[email-masked]>> wrote:
Hi Mike,

Best,
Shoko

On 2019/03/21 0:48, Michael Scott wrote:
> On Tue, Mar 19, 2019 at 3:39 AM Shoko YONEZAWA <[email-masked]<mailto:[email-masked]>>
> wrote:
>
>> Dear Mike,
>>
>>> On Thu, Mar 14, 2019 at 3:21 PM Michael Scott <[email-masked]<mailto:[email-masked]>>
>> wrote:
>>>
>>>> Hello,
>>>>
>>>> On Wed, Mar 13, 2019 at 10:33 AM Shoko YONEZAWA <[email-masked]<mailto:[email-masked]>
>>>
>>>> wrote:
>>>>
>>>>> Hi there,
>>>>>
>>>>> From: [email-masked]<mailto:[email-masked]>
>>>>> Reply-To: [email-masked]<mailto:[email-masked]>
>>>>> To: [email-masked]<mailto:[email-masked]>
>>>>>
>>>>>
>> https://datatracker...ietf.org/doc/draft-yonezawa-pairing-friendly-curves/<https://datatracker.ietf.org/doc/draft-yonezawa-pairing-friendly-curves/>
>>>>>
>>>>> until the htmlized version and diff are available at tools...ietf.org<http://tools.ietf.org>.
>>>>>
>>>>> [email-masked]<mailto:[email-masked]>
>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html<http://www.ietf...org/shadow.html>
>>>>> [email-masked]<mailto:[email-masked]>
>> [email-masked]..jp<mailto:[email-masked]>
>> TEL: +81-3-6276-5103
>>
>
>
> [email-masked]<mailto:[email-masked]>

--
Shoko YONEZAWA
Lepidum Co. Ltd.
[email-masked]<mailto:[email-masked]>
TEL: +81-3-6276-5103

_______________________________________________
Cfrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/cfrg
_______________________________________________
Cfrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/cfrg

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 29 Mar 2019 16:59:36 +0000

So far I’ve found this (which IMHO doesn't look like a set of good arguments):

>  1) Pairing-based crypto threw open the doors to lots of nice new crypto possibilities, enabling stuff that we couldn't do before
>  2) Gradually post-quantum crypto is catching up and demonstrating capabilities that mirror some (but not all) of these achievements
>  3) Post-quantum crypto depends on hard problems that it will take time to develop full confidence in, even in regard to attacks from non-quantum computers
>  4) In the meantime (and that could be quite a long time) it makes perfect sense to proceed with the development and standardization
>       of non-quantum safe methods.
>  5) In the year x out pops a quantum computer. However in the year x-1 out popped well-developed and well-understood
>       post-quantum crypto replacements in which we can have complete confidence. 

Re. (1): sure, it would do great stuff, but for how long? What’s the expected lifetime of an algorithm/protocol/approach that would justify efforts spent on formalizing, implementing, and deploying it? What application field or use case would support it?

Re. (2) and (3): sure, but irrelevant with regard to the main question - is it worth developing (for deploying later, as there's an inevitable lag) non-quantum-resistant crypto now?

Re. (4): I see no logic in that statement. We don't have full confidence in post-quantum hard problems, therefore we should standardize methods that we know are not quantum-resistant?

Re. (5): It's only true for data that loses value rapidly. It may work for, e.g., throw-away TLS sessions, but not for, e.g., sensitive email. It seems to ignore the fact that data produced in year x-k (encrypted by good and intercepted by bad players) may still have value in year x, x+1, etc.

I cannot (nor do I want to) tell people what to research or experiment with, and what not to. But common sense suggests that systems/algorithms that do not offer long-term protection won't see large-scale commercial deployment, IRTF draft or not.

---

From: Michael Scott <[email-masked]>
Date: Fri, 29 Mar 2019 22:05:47 +0000

Hey those are my arguments (and damned fine ones they are too!). Kenny
liked them!

Really, you should be polite enough to directly attribute them to me.

(Am I being trolled???)

Mike

> Naïve question: how is this approach supposed to weather in post-quantum
world?

On Fri, Mar 29, 2019 at 5:00 PM Blumenthal, Uri - 0553 - MITLL <
[email-masked]> wrote:

> It doesn’t but we did already discuss that, and good arguments were put
> forth for continuing the work despite this. (See the mail archive, I guess.)
>
> >  1) Pairing-based crypto threw open the doors to lots of nice new crypto
> possibilities, enabling stuff that we couldn't do before
> >  2) Gradually post-quantum crypto is catching up and demonstrating
> capabilities that mirror some (but not all) of these achievements
> >  3) Post-quantum crypto depends on hard problems that it will take time
> to develop full confidence in, even in regard to attacks from
> non-quantum computers
> >  4) In the meantime (and that could be quite a long time) it makes
> perfect sense to proceed with the development and standardization
> >  5) In the year x out pops a quantum computer. However in the year x-1
> out popped well-developed and well-understood
> Re. (1): sure, it would do great stuff, but for how long? What’s the
> expected lifetime of an algorithm/protocol/approach that would justify
> efforts spent on formalizing, implementing, and deploying it? What
> application field or use case would support it?
>
> Re. (2) and (3): sure, but irrelevant with regard to the main question -
> is it worth developing (for deploying later, as there's an inevitable lag)
> non-quantum-resistant crypto now?
>
> Re. (4): I see no logic in that statement. We don't have full confidence
> in post-quantum hard problems, therefore we should standardize methods that
> we know are not quantum-resistant?
>
> Re. (5): It's only true for data that loses value rapidly. It may work
> for, e.g., throw-away TLS sessions, but not for, e.g., sensitive email. It
> seems to ignore the fact that data produced in year x-k (encrypted by good
> and intercepted by bad players) may still have value in year x, x+1, etc.
>
> I cannot (nor do I want to) tell people what to research or experiment
> with, and what not to. But common sense suggests that systems/algorithms
> that do not offer long-term protection won't see large-scale commercial
> deployment, IRTF draft or not.
>
>

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Sun, 31 Mar 2019 01:00:56 +0000

Well, I simply did not want to embarrass you publicly, as, frankly, I thought those arguments were poor (regardless of whether Kenny liked them or not) - as I explained in my post.

My points were brief enough that either you or Kenny can show where they are wrong, if you can. 

If there are other arguments - I'd be happy to hear them.

Regards,
Uri

P.S. Since you wrote the MIRACL library, I wouldn't expect such a post from you. But, whatever...

Sent from my iPhone

> On Mar 29, 2019, at 18:06, Michael Scott <[email-masked]> wrote:
> 
> Hey those are my arguments (and damned fine ones they are too!). Kenny liked them!
> 
>> On Fri, Mar 29, 2019 at 5:00 PM Blumenthal, Uri - 0553 - MITLL <[email-masked]> wrote:

---

From: Michael Scott <[email-masked]>
Date: Sun, 31 Mar 2019 20:28:44 +0100

Hello Shoko,

Thanks for previous clarifications.

I am a bit puzzled by the proposed BN462 curve

You chose the curve E:y^2=x^3+5
On the twisted curve you choose E':y^2=x^3-u+2 (and I am unclear where -u+2
came from)

In the paper that first suggested the curve -
https://eprint.iacr.org/2017/334.pdf

the authors suggest
E: y^2=x^3-4, and
E': y^2=x^3-4(1+u)

which seems simpler, and closer to the BLS381 approach

I am attempting to implement these curves (and already have BLS381 done).
Any help is much appreciated.

Mike

On Fri, Mar 29, 2019 at 10:03 AM Shoko YONEZAWA <[email-masked]>
wrote:

> not
> >>   > interoperability, as well as for G1. For example an implementation
> of
> >> BLS
> >>> On Tue, Mar 19, 2019 at 3:39 AM Shoko YONEZAWA <[email-masked]
> >
> >>> wrote:
> >>>
> >>>> Dear Mike,
> >>>>
> >>>>> On Thu, Mar 14, 2019 at 3:21 PM Michael Scott <[email-masked]
> >
> >>>> wrote:
> >>>>>
> >>>>>> Hello,
> >>>>>>
> >>>>>> The draft does point out that for BLS curves, when hashing to a
> point
> >> in
> tools.ietf.org..