[CFRG] Re: Pairing-Friendly Curves: Open Questions Before Draft Update

[Yumi Sakemi <[e-mail]>]

Hi Diego,

Thank you for the detailed explanation on the word-boundary rationale — the
argument that field sizes just above a word boundary (like BN462 and
BLS48_581) decrease performance without a practical security gain is clear
and well-supported. Guillevic's analysis is a helpful reference.

Your explanation also addressed my question about why BLS24-509 is
preferred over BLS24-479: the 509-bit field is the minimum for ~192-bit
security under current analysis (Aranha–Guillevic), while still fitting in
8 × 64-bit words. Thank you for clarifying this.

To move the discussion forward, I'd like to follow up on the remaining item
from my earlier email. The draft's selection policy (Section 4) asks that
recommended curves be (1) peer-reviewed, (2) widely used in libraries, and
(3) prioritize security over efficiency. Your response covered the
security/efficiency rationale well. For the "widely used" criterion, could
you share:

BLS24-509: Are there additional library implementations or deployed systems
beyond RELIC and the Rust implementation referenced in PR #70?
BN446 and BLS48-575: Peer-reviewed references and library implementations
for these curves, so the group can evaluate them under the same criteria.
I recognize that adoption for newer curve parameterizations may still be
limited compared to the established curves — that's understandable. Having
the concrete data would help the group assess where each proposal stands
relative to the selection policy, especially since the current parameter
set has already passed expert crypto panel review. Any changes to the
recommended curves would need to be carefully evaluated by the community.

We are also preparing GitHub issues to organize the discussion items from
the December 2025 Open Questions thread (serialization, identity point
handling, etc.) and will notify the list once those are filed. The curve
selection discussion is best continued here on the ML where it has broader
visibility.

Best regards,
Yumi

2026年3月20日(金) 5:08 Diego F. Aranha <[e-mail]>:

> Dear Yumi,
>
> The rationale for the suggested curves is essentially the same: Ideal
> parameters have the field size close to a word boundary, so we have the
> best cost-benefit between performance and security.
>
> Because most platforms of interest for pairing-based cryptography are 32-
> and 64-bit CPUs, it is ideal that field sizes are slightly under multiples
> of 32 and 64, so there is extra space to handle carries and optimize
> extension field arithmetic in G2 and GT. Of course this assumes that lower
> bounds on the group order are also satisfied for dlog-security.
>
> In short:
> - The base field of BLS24-479 takes 15 32-bit words and 8 64-bit words.
> BLS24-509 takes 16 32-bit words and the same 8 64-bit words. Considering
> that the analysis in Aranha-Guillevic establishes 509-bit fields as the
> minimum for ~192-bit security under current attacks, BLS24-509 has a better
> security/performance trade-off between the two.
> - Curves BN462 and BLS48_581 have field sizes just a few bits above a word
> boundary (14 and 5 respectively), decreasing performance at no practical
> gain in security. Guillevic supports the same argument with concrete
> numbers at
> https://people.irisa.fr/Aurore.Guillevic/Pairing_friendly_curves.html#bls12-381-bls12-461-or-bls12-446
>
> I will follow-up later with a comparison between levels of
> adoption/support for these parameter choices.
> --
> Diego F. Aranha
> Associate Professor at Computer Science - Aarhus University, Denmark
> https://dfaranha.github.io/
>
> Åbogade 34, Building 5335 (Office 291 at Nygaard)
> 8200 Aarhus N, Denmark
>
>
>
> <https://sites.google.com/site/dfaranha>
>
>
> On Tue, Mar 17, 2026 at 7:11 AM Yumi Sakemi <[e-mail]>
> wrote:
>
>> Hi Diego,
>>
>>  Thank you for your PRs (#70 and #71) —
>> I appreciate your contributions to the draft.
>>
>>  I wanted to let you know that I have just synced the GitHub repository
>> with the latest version on datatracker (v12).
>> The main change is a migration from RFC XML to kramdown-rfc Markdown
>> format.
>>  As a result, your PRs may have conflicts with the updated master branch.
>>
>> Could you please rebase them against the current master when you have a
>> chance?
>>
>>  Regarding the BLS24-509 proposal in PR #70,
>> I plan to start a discussion on the CFRG mailing list to evaluate it
>> against the selection policy defined in Section 4 of the I-D.
>> I'll send that email separately.
>>
>> Best regards,
>> Yumi
>>
>>
>> 2026年3月17日(火) 9:44 Yumi Sakemi <[e-mail]>:
>>
>>> Dear all,
>>>
>>> Thank you Diego for the proposal and for posting to the list.
>>>
>>> We are currently updating the GitHub repository to sync with the latest
>>> datatracker version (draft-irtf-cfrg-pairing-friendly-curves-12). Once that
>>> is done, PR #70 will show a clean diff for easier review.
>>>
>>> To help the group evaluate this proposal, I'd like to walk through the
>>> draft's selection policy (Section 4). The policy states that recommended
>>> curves should (1) have security demonstrated in peer-reviewed papers, (2)
>>> be widely used in cryptographic libraries, and (3) prioritize security over
>>> efficiency.
>>>
>>> For BLS24-509 at the 192-bit security level:
>>>
>>>    - *Peer review:* The security analysis has been published in CIC
>>>    2024 (ePrint 2024/1223), which is a peer-reviewed IACR venue. This appears
>>>    to satisfy criterion (1).
>>>    - *Library support:* PR #70 references two implementations — RELIC
>>>    and an independent Rust implementation (efficient-rust-pairings by Faraoun
>>>    Kamel Mohamed). For reference, the current draft cites 4–5 library
>>>    implementations for BN462 and BLS48_581. Are there additional libraries or
>>>    deployed systems using BLS24-509 beyond these two? It would help the group
>>>    to understand how the level of adoption compares with the currently
>>>    recommended curves.
>>>
>>> Additionally, I note that MIRACL Core includes BLS24-479 as an
>>> experimental 192-bit BLS24 curve, which is a different parameterization
>>> from BLS24-509. Diego, could you briefly explain why BLS24-509 is the
>>> preferred candidate over other BLS24 parameterizations at this security
>>> level?
>>>
>>> Regarding the suggestion to replace BN462 with BN446 and BLS48_581 with
>>> BLS48-575: these changes are not yet included in PR #70. If we want to
>>> discuss these as well, it would be helpful to have the same information —
>>> peer-reviewed references and library implementations — so the group can
>>> evaluate them under the same selection criteria.
>>>
>>> Looking forward to the discussion.
>>>
>>> Best regards,
>>>
>>> Yumi
>>>
>>> 2026年3月17日(火) 6:18 Diego F. Aranha <[e-mail]>:
>>>
>>>> Dear all,
>>>>
>>>> Thank you for the work so far in this draft!
>>>>
>>>> We propose to include a BLS24 curve at the 192-bit security level, now
>>>> that candidates are clear.
>>>> This PR includes parameters and test vectors, and points to security
>>>> analysis:
>>>> https://github.com/cfrg/draft-irtf-cfrg-pairing-friendly-curves/pull/70
>>>>
>>>> I believe keeping a BN curve is useful for backwards compatibility and
>>>> to benefit from acceleration to prime-order curves that may be already
>>>> available in selected hardware.
>>>> However, I would claim that BN446 and BLS48-575 are respectively better
>>>> options than the BN462 and BLS48_581 curves included in the standard.
>>>> They offer very similar bit-security while requiring one less word to
>>>> represent field elements, giving a non-trivial speedup in practice.
>>>>
>>>> Please let us know if there are any objections to these changes.
>>>>
>>>> Sincerely,
>>>> --
>>>> Diego F. Aranha
>>>> Associate Professor at Computer Science - Aarhus University, Denmark
>>>> https://dfaranha.github.io/
>>>>
>>>> Åbogade 34, Building 5335 (Office 291 at Nygaard)
>>>> 8200 Aarhus N, Denmark
>>>>
>>>>
>>>>
>>>> <https://sites.google.com/site/dfaranha>
>>>> _______________________________________________
>>>> CFRG mailing list -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>>>
>>>