[CFRG] Re: draft-irtf-cfrg-pairing-friendly-curves-13: closing #74 and #84 (comments by Aug 3)

[Emil Lundberg <[e-mail]>]

Hi Yumi,

Yes, here are the issues I found with the serializations and
deserializations:

1. The octet string encoding in Section 2.5
<https://www.ietf.org/archive/id/draft-irtf-cfrg-pairing-friendly-curves-13.html#name-representation-convention-f>
(from ietf-lwig-curve-representations) is little-endian (polynomial
coefficients in ascending order s_0 + s_1*i + s_2*i^2 + ... for both
polynomials over GF(p) and over GF(p^d)), while the serializations in
section 5 are big-endian (coefficients in descending order). But it also
seems like section 2.5 is not referenced anywhere, at least within this
same document? So perhaps section 2.5 can be deleted, then.

Sections 4.2 and 4.3 as well as Appendix C still write polynomials in
little-endian order, but I don't think that is a problem since the
indeterminate powers are explicitly written out each time to disambiguate.

2. The deserialization procedure in section 5.3
<https://www.ietf.org/archive/id/draft-irtf-cfrg-pairing-friendly-curves-13.html#name-point-deserialization-proce>
implicitly only works for E(GF(p)): Steps 5-7 unconditionally parse the
whole x_string (and y_string where present) using OS2IP; for E' the
coordinates need to be split into m parts. I can submit a pull request to
GitHub with a suggested fix if you'd like (you are of course welcome to
edit it however you like to fit your writing style).

3. Also in section 2.5, the reference [MP04] is described as "Cocks–Pinch
curves of embedding degrees five to eight and optimal ate pairing
computation" in "Cryptology ePrint Archive Report 2019/431, 2019", but the
eprint link leads to "Compressed Pairings" by Scott and Barreto which is
2004/032. The reference text seems like it should point to
https://eprint.iacr.org/2019/431 , but the reference in section 2.5 is
"using the compression method [MP04] may be more effective." which does
seem to rather refer to "Compressed pairings". Although this reference may
be redundant if section 2.5 is deleted as discussed in point (1).

I also have some more review comments unrelated to issues #74 and #84, so
I'll post them separately. Thanks again for your work!

Emil Lundberg

Staff Engineer | Yubico <http://www.yubico.com/>




Den mån 27 juli 2026 kl 08:25 skrev Yumi Sakemi <[e-mail]
>:

> Hi Emil, and CFRG,
>
> Thank you again for the discussion during the pairing-friendly-curves slot
> at IETF 126 last Friday -- both the feedback on the draft and the chairs'
> guidance on next steps were very helpful.
>
> Two quick follow-ups:
>
> To Emil -- during Q&A you mentioned spotting an issue with the
> specification of the serialization procedure, but didn't have time to go
> into the details. Would you mind sharing what you found (on the list or on
> GitHub, whichever is easier)? We'd like to file it as an issue and get it
> fixed.
>
> As the chairs suggested in the session, we're planning to close issues #74
> and #84, since we believe -13's Section 5 addresses them. If anyone has
> comments or objections, we'd appreciate hearing them by August 3rd, before
> we close them out and move toward the next Crypto Panel review.
>
> Thanks again,
> Yumi
>
>
>
>
> --
>
> ---
>
> Yumi SAKEMI
>
> GMO CONNECT, Inc.
>
> [e-mail]
>