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

[Yumi Sakemi <[e-mail]>]

Hi Diego,

Thanks for the detailed analysis -- the performance numbers, the
word-boundary
observations, and the [GMT19] and [GS20] security-bit figures. We accept the
performance and word-boundary points as real costs under criterion (3).
Below we
set out the principle that drives the 128-bit and 256-bit selections,
because we
think it answers your points more directly than a curve-by-curve bit count.

The selection principle
Where this document has a free choice, it selects curves with security
margin
above the nominal level. It departs from that principle in exactly one
place:
BLS12-381, retained at ~126 bits -- slightly below the 128-bit target --
because
its existing deployment (Ethereum, Zcash, and downstream protocols) is too
large
to set aside. That single departure is driven by criterion (2), wide use.
Section 4 ranks criterion (3), efficiency, below (2); efficiency therefore
does not earn
the same departure.

This is the lens for the two levels you raise.

128-bit
The 128-bit level has two curves, with distinct roles. BLS12-381 is the
deployment curve; at ~126 bits it does not itself provide margin. BN462 --
one
bit above BN-461, the minimum-size BN curve for which [GMT19] / [GS20] give
134-135 bits -- lands in the same security range and gives the level a
member
comfortably above 128-bit. The pair lets an implementer choose: BLS12-381
for
interoperability, BN462 for assured margin.

Replacing BN462 with BN446 (~132 bits) would leave the level as {~126,
~132} --
no curve with real headroom against future cryptanalytic refinement. The
second
slot exists precisely to provide what BLS12-381 cannot; that role needs
BN462.

We do not dispute that BN446 is faster, or that 462 mod 64 = 14 is a real
cost.
Those are criterion (3) considerations. The point is that BN446's only
advantage
is (3), and (3) does not, under Section 4, buy a reduction in the level's
margin.

(On the apparent asymmetry -- accepting ~126-bit BLS12-381 but not ~132-bit
BN446: BLS12-381's sub-target security is an accepted cost of an unavoidable
reality, a curve the world already runs on. Selecting BN446 would be freely
choosing a lower-margin curve where we have no such constraint. Tolerating
what
cannot be changed is not the same as choosing it.)

256-bit
The 256-bit level is the document's safety net against future progress
against
the 128-bit level. It has no deployment base -- as we noted on 17 May,
neither
BLS48-581 nor BLS48-575 is widely used -- so the criterion (2) exception
that
carries BLS12-381 has no analogue here. With wide use not in play, the
margin
principle applies without exception. [KIK17]'s ~572-bit figure is itself an
estimate; BLS48-575 sits just above it, BLS48-581 unambiguously above. For a
level whose entire purpose is margin, we take the curve that keeps its
security
level robust if that estimate is later refined.

Choosing BLS48-575 would relax margin for efficiency alone -- again a
criterion
(3) reason, which Section 4 subordinates. We acknowledge 581 mod 64 = 5 as a
genuine (3) cost.

192-bit
This remains an open scope question for the RG (Issue #67), not an authors'
decision. We do not oppose inclusion; if the RG forms consensus to include
the
level, our recommendation is BLS24-559 -- the candidate you also described
as
"a more defensible trade-off" over BLS24-509. The same margin principle
supports
it: [BD18] (Table 9 / §7.2) places the BLS24 worst-case parameter size at
|p|~=554; 559 is above it, 509 below.

Process
We would welcome the chairs gauging consensus, particularly on the 192-bit
scope
question. For 128-bit and 256-bit, our case is the single principle above;
if
the chairs judge a consensus call is warranted there too, we will of course
follow the RG's decision.

Small item
Apologies for listing "BLS12-461" in the 17 May enumeration -- as you
noted, it
is not a 192-bit candidate. Please disregard.

Thanks again for the careful review.

Best regards,
Yumi Sakemi (editor; with Satoru Kanno)

2026年5月21日(木) 16:47 Diego F. Aranha <dfaranha=[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]>:
>
> 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]
>
>