Subject: [CFRG] Re: I-D Action: draft-irtf-cfrg-pairing-friendly-curves-12.txt
From: Nick Sullivan <[email-masked]>
To: John Bradley <[email-masked]>
Cc: John Mattsson <john.mattsson=[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 18 Nov 2025 17:29:09 -0500
List-Id: Crypto Forum Research Group <cfrg.irtf.org>

Hi John^2,

This draft is being revisited presently, and any feedback from the group is
welcome, especially now.

If you missed it, Yumi gave a presentation at IETF 124 on the state of
things after the last RGLC. Since then, the chairs have been in touch with
the authors and with some new contributors who want to help with this
effort. We think there's momentum to continue this work and to get a draft
to RGLC again, though it may require setting up an interim meeting between
now and IETF 125 to tie everything up.

I'll start a thread by the end of the week to summarize the state of
affairs. There are still open questions, so it would be great to capture
them in that thread so we can reach consensus on a strategy for moving
forward on the topic of pairing-friendly curves.

Because many higher-level algorithms may rely on the recommendations in
this specification, it's important that we cover the topic in a way that
considers
- how best to help IETF engineers understand the security considerations of
protocols that use pairing-friendly curves
- the rationale behind which concrete parameter choices we list and produce
test vectors for
- whether this draft is opinionated about interfaces and abstractions
around these primitives (mapping to h2c for example)

Nick

On Tue, Nov 18, 2025 at 10:06 AM John Bradley <[email-masked]> wrote:

> Thanks, John M.
>
> That aligns with the feedback I have been getting over the last couple of
> weeks.
>
> Now that I am back from TPAC, I will try to follow up with the curves
> authors.
>
> Any feedback on BLS signatures?
>
> Regards
> John B.
>
> On Nov 18, 2025, at 5:47 AM, John Mattsson <john.mattsson=
> [email-masked]> wrote:
>
> Hi,
>
> I think it would be good to try to publish this asap. My two cents would
> be to focus on specifying:
>
> - BLS12_381
> - One BLS24 curve, one BLS48 curve, or both. I think many people might
> want some security margin when deploying pairing-based crypto.
> -  The ZCash serialization format
>
> I don't think "Selection of Pairing-Friendly Curves" including what is
> standardized in other SDO is essential. I think BN462 could be removed.
> less is more. Correctly if I am wrong but my understanding is that
> BLS12_381 is superior to BN462. Security of Pairing-Friendly Curve could be
> moved to security consideration or an appendix.
>
> Cheers,
> John
>
> On 2025-11-02, 22:17, "[email-masked]" <[email-masked]>
> wrote:
>
> Internet-Draft draft-irtf-cfrg-pairing-friendly-curves-12.txt is now
> available. It is a work item of the Crypto Forum (CFRG) RG of the IRTF.
>
>    Title:   Pairing-Friendly Curves
>    Authors: Yumi Sakemi
>             Satoru Kanno
>             Riad S. Wahby
>    Name:    draft-irtf-cfrg-pairing-friendly-curves-12.txt
>    Pages:   54
>    Dates:   2025-11-02
>
> Abstract:
>
>    Pairing-based cryptography, a subfield of elliptic curve
>    cryptography, has received attention due to its flexible and
>    practical functionality.  Pairings are special maps defined using
>    elliptic curves and it can be applied to construct several
>    cryptographic protocols such as identity-based encryption, attribute-
>    based encryption, and so on.  At CRYPTO 2016, Kim and Barbulescu
>    proposed an efficient number field sieve algorithm named exTNFS for
>    the discrete logarithm problem in a finite field.  Several types of
>    pairing-friendly curves such as Barreto-Naehrig curves are affected
>    by the attack.  In particular, a Barreto-Naehrig curve with a 254-bit
>    characteristic was adopted by a lot of cryptographic libraries as a
>    parameter of 128-bit security, however, it ensures no more than the
>    100-bit security level due to the effect of the attack.  In this
>    memo, we list the security levels of certain pairing-friendly curves,
>    and motivate our choices of curves.  First, we summarize the adoption
>    status of pairing-friendly curves in standards, libraries and
>    applications, and classify them in the 128-bit, 192-bit, and 256-bit
>    security levels.  Then, from the viewpoints of "security" and "widely
>    used", we select the recommended pairing-friendly curves considering
>    exTNFS.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-irtf-cfrg-pairing-friendly-curves/
>
> There is also an HTML version available at:
>
> https://www.ietf.org/archive/id/draft-irtf-cfrg-pairing-friendly-curves-12.html
>
> A diff from the previous version is available at:
>
> https://author-tools.ietf.org/iddiff?url2=draft-irtf-cfrg-pairing-friendly-curves-12
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
>
> _______________________________________________
> CFRG mailing list -- [email-masked]
> To unsubscribe send an email to [email-masked]
>
>
> _______________________________________________
> CFRG mailing list -- [email-masked]
> To unsubscribe send an email to [email-masked]
>