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

[SAITO Tsunekazu <[e-mail]>]

Dear Rene 

Thank you for the information about your draft.
We also know that the BLS signature implementation uses concatenation.

Like these implementations of conversion by concatenation, 
this draft should be adapted to the method of concatenation. 
We will change to Method B.

Moreover, now there are two conversion methods of extension field element.
Thus we will add a remark  so that implementer will not make a mistake.

Best Regards,
Tsunekazu

From: Rene Struik <[e-mail]> 
Sent: Thursday, September 19, 2019 11:09 PM
To: SAITO Tsunekazu <[e-mail]>; [e-mail]
Subject: (offline) Re: [Cfrg] Call for adoption: draft-yonezawa-pairing-friendly-curves

Hi Saito:

Indeed, there are trade-offs with the various data conversion methods. In my curve draft (Annex J.4 [1]) I used method B, as does the SIKE PQC submission to NIST's post-quantum contest. My choice mostly motivated by desire for consistency (so that others could simply cross-reference this) and extreme ease in processing (and can be easily implemented securely). 

Best regards, Rene

Ref: 
[1]https://tools.ietf.org/html/draft-ietf-lwig-curve-representations-08#page-53
[2] Supersingular Isogeny-Based DH - SIDH-spec (David Jao et al, NIST PQC Project, November 30, 2017)


On 9/19/2019 6:57 AM, SAITO Tsunekazu wrote:
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 mailto:[e-mail] 
Sent: Friday, September 6, 2019 10:52 PM
To: Paterson Kenneth mailto:[e-mail]; mailto:[e-mail]
Cc: mailto:[e-mail]; mailto:[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
mailto:[e-mail]
https://www.irtf.org/mailman/listinfo/cfrg


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


_______________________________________________
Cfrg mailing list
mailto:[e-mail]
https://www.irtf.org/mailman/listinfo/cfrg

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