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

[Rene Struik <[e-mail]>]

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 <[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]
>
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg


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