Re: [Cfrg] Call for adoption: draft-yonezawa-pairing-friendly-curves

[SAITO Tsunekazu <[e-mail]>]

Dear Rene

This is SAITO Tsunekazu. I am the co-author of draft-yonezawa.

Thank you for your comments about data conversion in Section 2.5.
We will be careful to correct the typo etc. in the next draft. 

(1) Description of Data Conversion
Riad also asked us if we need to describe data conversion.
At that time, Shoko responded that we were considering just a mathematical parameter range as the draft range.
Certainly, if it is necessary to describe the data conversion for implementation, we can describe it separately in the appendix as follows.
https://info.isl.ntt.co.jp/crypt/psec/dl/iso/psec-kem_v2.2_20080414e.pdf

(2) Data Conversion Between Extension Field Element and Octet String.
There are two main methods for this conversion as you said.

(A) a method to assign the characteristic to an indeterminate.
For extension field element as polynomial x = s_0 + s_1 * u + ... + s_{n-1} *u^{n-1}, one assign the prime and compute an integer
int(x) = s_0 + s_1 * p + ... + s_{n-1} *p^{n-1}.
Then we convert to octet string. 

Advantages of this method are
* Adopted by other standards like IEEE and ANSI to ensure consistency.
* You only need to check if the element of the finite field is correct when converted to an integer.

(B) a method of concatenation of each coefficient.
For extension field element as polynomial x = s_0 + s_1 * u + ... + s_{n-1} *u^{n-1}, one concatenate each coefficient s_i oct (x) = s_0 ||s_1|| ... ||s_{n-1}. 

Advantages of this method are
* Fast implementation.
* Easy to implement. 

We understand that there are good points to either method, so we briefly described the conversion method of (A) according to different standards and historical backgrounds. 

Best Regards,
SAITO Tsunekazu

-----Original Message-----
From: Rene Struik <[e-mail]> 
Sent: Friday, September 6, 2019 10:52 PM
To: Paterson Kenneth <[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: [Cfrg] Call for adoption: draft-yonezawa-pairing-friendly-curves

Dear colleagues:

I am neutral with respect to adoption of this draft.

I do have an organizational remark regarding CFRG work items, though: if this draft is adopted by the CFRG as a working group document, I would suggest moving the description of the curves isogenous to BLS-12-381 as described in Appendix C of draft-irtf-cfrg-hash-to-curve-04 to the pairing curve document, so as to keep the curve mapping document clean and keep all core pairing-related stuff in one document.

Section 2.5:
a) s = s_0 + s_1 * p + ... + s_{d - 1} * i^{d - 1} should read s = s_0 +
s_1 * i + ... + s_{d - 1} * i^{d - 1}, since it is a polynomial in indeterminate i.
b) Is there a a reason to represent this as s = s_0 + s_1 * p + ... + s_{d - 1} * p^{d - 1}, in lowest-coefficient-first order, rather than in highest-coefficient-first order? Why not represent this as right-concatenation of the representation of the polynomial coefficients s_0, ..., s_{d-1} in GF(p) instead, so each of these can be easily extracted individually?
c) The IEEE 1363a-2004 specification referenced is not publicly available (well, without paying ~ $100).

Best regards, Rene

On 9/6/2019 7:36 AM, Paterson Kenneth wrote:
> Dear CFRG,
>
> This email commences a 2-week call for adoption for draft-yonezawa-pairing-friendly-curves:
>
> https://datatracker.ietf.org/doc/draft-yonezawa-pairing-friendly-curve
> s/
>
> Please give your views on whether this document should be adopted as a CFRG draft, and if so, whether you'd be willing to help work on it/review it.
>
> Thanks,
>
> Kenny (for the chairs)
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg


--
email: [e-mail] | Skype: rstruik
cell: [phone] | US: [phone]