[CFRG] Re: Pairing-Friendly Curves: authors' assessment and questions for the RG

[Yumi Sakemi <[e-mail]>]

Dear Diego,

Thank you for raising this concern.
The accessibility of standardsmatters, and
we agree that an open CFRG process should not be driven by
a proprietary document.
It is not — and we want to make this fully explicit,
because re-reading our previous post we can see how the references to
ISO/IEC 15946-5:2022 may have created that impression.

To clarify our framework first:

Our evaluation follows the Section 4 selection policy of the draft, in
this priority order:

  (1) Peer-reviewed security analysis
  (2) Wide use in cryptographic libraries and deployments
  (3) Efficiency

ISO/IEC 15946-5:2022 was cited in the previous post as *corroborating*
evidence under criterion (2) — alongside library star counts, deployment
data, and implementation activity — and as an additional cross-check on
specific u-values. It is not, and was not intended as, a load-bearing
input to any of our decisions. To demonstrate this, below we restate
each conclusion with ISO removed from the analysis.

---

128-bit level: BN462 retained, BN446 not adopted
------------------------------------------------

BN462 is selected on criteria (1) and (2):

  (1) Post-exTNFS security of ~134 bits in the peer-reviewed analysis
      of Barbulescu and Duquesne [BD18] and Guillevic, Masson, Thomé
      [GMT19] — both already cited in the draft (Section 2, Section 4).
  (2) Adoption across multiple independent libraries: mcl, MIRACL Core,
      and others.

BN446 is not adopted, again purely on (1) and (2):

  (1) The minimum p-size of 461 bits for BN/BLS12 curves under
      post-exTNFS analysis is established in [BD18] — this is the same
      reference the draft has used since adoption (Section 2, "461
      bits"). BN446 sits below this threshold. We note this guideline
      predates and is independent of ISO/IEC 15946-5:2022; our earlier
      phrasing that linked the two was unfortunate and we retract it.
  (2) Library adoption is limited to RELIC and one research-level
      implementation (efficient-rust-pairings, ~6 stars at time of
      writing), which does not meet the "widely used" bar that BLS12-381
      and BN462 clear.

BLS12-381 is retained for backward compatibility with production
deployments (Ethereum, Zcash, and downstream protocols), as already
discussed in the draft.

---

192-bit level: BLS24-559 recommended (if 192-bit is in scope)
-------------------------------------------------------------

No candidate at this level satisfies criterion (2) — none of BLS12-461,
BLS24-509, BLS24-559, etc. has the deployment footprint that BLS12-381
or BN462 have. When (2) does not differentiate the candidates, our
policy falls back to criterion (1) with the additional principle of
preferring a meaningful security margin when introducing a new level
for the first time:

  - 509-bit fields sit at the minimum boundary for ~192-bit security
    under post-exTNFS analysis [BD18], with no margin above the
    threshold.
  - 559-bit p provides explicit margin against future cryptanalytic
    progress.

This reasoning relies only on the peer-reviewed post-exTNFS analysis
and the draft's stated preference for margin at first introduction. No
ISO citation is required to reach the same conclusion.

---

256-bit level: BLS48-581 retained, BLS48-575 not adopted
--------------------------------------------------------

Neither BLS48-581 nor BLS48-575 satisfies criterion (2); both are below
the "widely used" bar. The 256-bit curve serves as a safety net against
compromise of the 128-bit level, so when (2) does not differentiate we
again apply criterion (1) plus security-margin preference:

  - For BLS48 curves, Kiyomura et al. [KIK17] estimate the minimum
    p-size for 256-bit security at ~572 bits.
  - BLS48-581 provides explicit margin above this threshold; BLS48-575
    sits essentially at it.
  - BLS48-575's efficiency advantage falls under criterion (3), which
    by Section 4 is ranked below both (1) and (2) and does not
    compensate for the absence of additional security margin.

Again, this conclusion does not depend on ISO/IEC 15946-5:2022.

---

In summary: our prior post mentioned ISO/IEC 15946-5:2022 as one of
several pieces of supporting evidence for criterion (2) and as a
cross-check on u-values. Removing it from the analysis does not change
any of the conclusions above; the primary justifications are the
peer-reviewed literature already cited in the draft ([BD18], [GMT19],
[KIK17]) and the documented library/deployment landscape.

We will reflect this clarification in Issue #76 so that the record is
unambiguous about which inputs drive the decisions.

References (already in draft-irtf-cfrg-pairing-friendly-curves-12):
  [BD18]  Barbulescu, R., Duquesne, S., "Updating Key Size Estimations
          for Pairings", J. Cryptol., 2019.
  [GMT19] Guillevic, A., Masson, S., Thomé, E., "Cocks-Pinch curves of
          embedding degrees five to eight ...", Des. Codes Cryptogr.,
          2020.
  [KIK17] Kiyomura, Y., et al., "Secure and Efficient Pairing at
          256-bit Security Level", ACNS 2017.

Best regards,
Yumi

2026年5月15日(金) 10:44 Diego F. Aranha <dfaranha=[e-mail]>:

> Dear Yumi,
>
> Thank you for the update.
>
> I see that the decisions heavily rely on ISO/IEC 15946-5:2022 Annex D for
> all 3 suggested security levels.
> However, this is a closed standard that the community in general does not
> have access to.
> I can't even double-check the parameters in the document because I refuse
> to pay CHF 185 to read them.
>
> Sorry, but I don't understand how being listed in a proprietary standard
> essentially mandates what curve should be standardized by the open CFRG
> process.
> --
> 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
> ------------------------------
> *From:* Yumi Sakemi <sakemi-yumi=[e-mail]>
> *Sent:* Friday, May 15, 2026 3:17 AM
> *To:* CFRG <[e-mail]>
> *Cc:* [e-mail] <[e-mail]>; Satoru Kanno <
> [e-mail]>
> *Subject:* [CFRG] Pairing-Friendly Curves: authors' assessment and
> questions for the RG
>
> Hi all,
>
> Thank you to Diego and all community members who engaged with Issue #76
> over the past weeks. The detailed references and discussion have given the
> authors a much clearer picture of the evidence for each criterion.
>
> The authors have now completed their internal evaluation against the
> Section 4
> selection criteria. We would like to share our assessment and seek the RG's
> input on the following two items.
>
> ---
>
> <Item 1: Should the 192-bit security level be brought into scope?>
>
> The current draft excludes 192-bit based on the consensus at adoption
> (Issue #67). Since then, community members -- including voices on the CFRG
> mailing list in late 2025 and early 2026 -- have expressed support for
> revisiting this decision.
>
> We ask the RG:
>
>   Is there now consensus to include a 192-bit security level in this RFC?
>
> If the RG supports inclusion, the authors recommend BLS24-559 for the
> following reasons:
>
> 1. Security margin. BLS24-559 provides explicit margin above the 192-bit
>    threshold. Under post-exTNFS analysis, 509-bit fields sit at the minimum
>    boundary for ~192-bit security, with no margin above it. When adding a
> new
>    security level to an RFC for the first time, we believe it is
> appropriate
>    to select with margin against future cryptanalytic progress.
>
> 2. No "widely-used" exception at this level. BLS12-381 is retained at
>    ~126-bit -- slightly below 128-bit -- because it satisfies the "widely
>    used" criterion. No 192-bit candidate currently meets that bar. Without
> a
>    compensating justification, accepting a minimum-threshold parameter
> would
>    be inconsistent with the draft's selection policy.
>
> 3. Existing standardization evidence. BLS24-559 is listed in
>    ISO/IEC 15946-5:2022 Annex D as a BLS24 numerical example (559-bit p),
>    providing independent validation of the parameter.
>
> If there is no substantial discussion, the authors will proceed with
> BLS24-559
> as the recommended 192-bit curve.
>
> ---
>
> <Item 2: 128-bit and 256-bit levels -- current curves retained>
>
> At both levels, the authors conclude that the current curves should be
> retained. The proposed alternatives do not meet the Section 4 selection
> criteria.
>
> The authors apply the Section 4 criteria in priority order:
>
>   1. Peer-reviewed security analysis
>   2. Widely used in cryptographic libraries
>   3. Efficiency (ranked below the above two)
>
> In addition, the authors maintain one parameter per security level as a
> guiding principle, to avoid confusion for users and implementers.
>
> 128-bit security level -> BN462 + BLS12-381 retained; BN446 not adopted
>
> BN462 satisfies both peer-reviewed security (134-bit post-exTNFS [GMT19])
> and wide library adoption (mcl, MIRACL Core, and others), and is listed in
> ISO/IEC 15946-5:2022 Annex D.2.3 with an exact u-value match.
> BLS12-381 is retained for compatibility with production deployments
> (Ethereum, Zcash, etc.).
>
> BN446 is not adopted. While it has a peer-reviewed security bound
> (132-bit [G20]), its library adoption is limited to RELIC (~700 stars) and
> efficient-rust-pairings (~6 stars, research-level). Additionally,
> |p| ~= 446 bits does not satisfy the post-exTNFS guideline of |p| >= 461
> bits introduced in the same ISO/IEC 15946-5:2022 edition that lists BN446
> as a numerical example.
>
> 256-bit security level -> BLS48-581 retained; BLS48-575 not adopted
>
> Neither BLS48-581 nor BLS48-575 satisfies the "widely used" criterion. The
> 256-bit curve serves as a safety net against compromise of the 128-bit
> level. Between the two options, BLS48-581 is preferred: it is the BLS48
> numerical example in ISO/IEC 15946-5:2022 Annex D.3.5 (exact u-value
> match) and provides the larger security margin. BLS48-575's efficiency
> advantage does not compensate for the lack of standardization evidence.
>
> ---
>
> The full evaluation table is available in Issue #76 for reference.
>
> We welcome any comments from the community by May 22, the current close
> date for this discussion.
>
> Best regards,
> Yumi
>
>
>
>
> --
>
> ---
>
> Yumi SAKEMI
>
> GMO CONNECT, Inc.
>
> [e-mail]
>