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

["Diego F. Aranha" <[e-mail]>]

Dear Yumi,

I finally got access to ISO/IEC 15946-5:2022, thanks to a kind file sharer, and I would like to comment on how some of the criteria is applied.

* 128-bit level:

  *
The ISO document gives BN-462 and BN-446 parameters. It cites both [BD18] and [G20] as sources of security analysis and does not prioritize one over the other. Personally, I would prioritize [G20] over [BD18] because it's follow-up work, with a more refined and precise analysis.
  *
[GS20] lists BN-446 as having 132 bits of security (Table 8) and BN-461 at 135 bits of security. [GMT19] lists BN-446 as having 132 bits of security and BN-461 as having 134 bits of security.
  *
As per [<https://people.irisa.fr/Aurore.Guillevic/Pairing_friendly_curves.html>1] and [2], you're losing up to 20% of performance for an increase of 3 bits of security, because you're paying the cost of one additional machine word with very little benefit (462 mod 32 = 462 mod 64 = 14).

* 192-bit level:

  *
I don't know why you mentioned BLS12-461 in your message, as it was not proposed for the 192-bit level at all and would obviously not meet the security level.
  *
Selecting BLS24-559 over BLS24-509 gives you 8 bits of security [3], at some 25% performance penalty [2].
  *
This is a more defensible trade-off, as the additional machine word is at least half-used (559 mod 32 = 15, 559 mod 64 = 47)

* 256-bit level:

  *
BLS48-581 gives you only tiny 1-2 extra bits of security (Fp^k is only 1% bigger), at some 25% performance penalty [2].
  *
This is the worst usage of an additional machine word among all candidates (581 mod 32 = 581 mod 64 = 5).

While these decisions may not be fully grounded in ISO/IEC 15946-5:2022, I find it difficult to reconcile them with the presented evidence, particularly in the cases of BN-462 and BLS48-581.
I understand criterion (1) takes priority, but 1-3 bits of security margin are not relevant enough for that to take precedence over a non-negligible performance penalty.

References:
[1] https://people.irisa.fr/Aurore.Guillevic/Pairing_friendly_curves.html
[2] https://github.com/kamel78/efficient-rust-pairings
[3] https://eprint.iacr.org/2019/885.pdf

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
________________________________
From: Yumi Sakemi <sakemi-yumi=[e-mail]>
Sent: Sunday, May 17, 2026 5:23 PM
To: Diego F. Aranha <[e-mail]>
Cc: CFRG <[e-mail]>; [e-mail] <[e-mail]>; Satoru Kanno <[e-mail]>
Subject: Re: [CFRG] Pairing-Friendly Curves: authors' assessment and questions for the RG

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]<mailto:[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]<mailto:[e-mail]>>
Sent: Friday, May 15, 2026 3:17 AM
To: CFRG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; Satoru Kanno <[e-mail]<mailto:[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]<mailto:[e-mail]>