Return-Path: X-Original-To: cfrg@mail2.ietf.org Delivered-To: cfrg@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 4D81A8C058AF for ; Tue, 18 Nov 2025 14:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRuO5YryUgsE for ; Tue, 18 Nov 2025 14:29:20 -0800 (PST) Received: from mail-yx1-xb135.google.com (mail-yx1-xb135.google.com [IPv6:2607:f8b0:4864:20::b135]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id B1E2C8C0589E for ; Tue, 18 Nov 2025 14:29:20 -0800 (PST) Received: by mail-yx1-xb135.google.com with SMTP id 956f58d0204a3-6420c0cf4abso2110635d50.1 for ; Tue, 18 Nov 2025 14:29:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763504960; x=1764109760; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=pKcq9rKc6c6ZJdhMwxs4Uwl9ZH6N0f47raBEk2s6ahc=; b=f/ziAqqewcLq/plk4EEIG1LoAYlWwOj7rmsKKgKQNjBumaEPgDn9F/aU+u8xXD+weQ sTaj7o7n2oxGqMR8AWZRa1w9YIoctN5zRHUwicyjvYZOUhmEBS53bG4QFm1Iv6+/m/p8 zhv5nM+WyR4p1XRJbVj98+5iJZVgX9vTq8YjVPOtZXRW/HxtZD2xji3oG94eo5z+qFaD rsDMEKz9Ej3NTU6H8LOF3j48j19tsyM8Uhq9XA1Y5fquU/dIBlekAkieSmHrVRWICGca +FUueR3x+PGLwmDT7CAV0JRt4SNX5nKBS0l3VjjESbxqeRhYuzQIKFMf5XvwtybXsCDL 1OWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763504960; x=1764109760; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=pKcq9rKc6c6ZJdhMwxs4Uwl9ZH6N0f47raBEk2s6ahc=; b=f1vObPt+RW1cc+VxhZ9jxlSYsPh2ys+cB+1QEnOkMu9CFSDrpSpigdXBCT4pt0sl97 HKesooBslQXyhyAzbTanr/HW9uL+A5/O0PL7AWqixcD5xU4jrQchC5cP9+7hQR17e7oz TY3uqTvfT18+I3NyUMEkiICTu/FC3Fc7940vTo5LI3DUVefycJ8thU3O1ut6Nm7PaquI 4r52mZIZCHhkrKnlyNirny0HIkIknidHaV1Q75p05lGXgp3yPCwYADYcf1WYjSGO50jy TTnPUqgCoxNg1q/7AaUu2uHIXjS69zzT5B+Kp+71CoZdCXzTcp6WY26fqmxMmFxr/bWl 64jg== X-Forwarded-Encrypted: i=1; AJvYcCXUxjedNqrw6fzVUg6VndfqcBddtxZnMq2pTkrKZXnj6bCp6e/lD3MkkcFSko+hTr7bpgB0@ietf.org X-Gm-Message-State: AOJu0YxhOYF0DFpy6QBt+HVnaybH6MNh74H97QNv76wGAjGlvuN6f40/ byaNVxIvRMRHnBMWzUmxdmpA0kIPXinNd60qLGrTEh6tkAw9taQ+SWt3E0ZzHvh7UOa+WR5iz/6 Dknvh9kvvVyLlOLSrCWleVFpPMycIAN+n3QJgimU= X-Gm-Gg: ASbGncucLNJ1MzKni+NWiToZeoFasSAmR7mI5cyHMtNGjPnJ6ykyEGuJu1S/L1qx20+ 2mfDR1wihsdkdKQi5LMWZtcee0UKqQO/hAINjB0Z/Ras+WNUbEakhOIGttCwEWqm1sz7qsG3KZd MhiQf6O8k4vPPataXWPTc/kHSwvurP58ifYgr1go41HGHhr4UqsQE2aJDha5zj3huFnXzf156D+ W8Fsqph5G0fm3RlQr4JTsZT+RGjXmGpr/3db7T4JW4Q73k5so8AgQ2RQXm25MrkaACwWVX0Sm4G 6Zyy1kq9UAp1dZOvUMyWs+S0eucDXk1FOLL/nEIOhAwwbuW5ryGT1BEea1wA7bnLN8QCrwk0Ue4 0DWBGJh8= X-Google-Smtp-Source: AGHT+IEaDIYSdWBd4us94/45Ynad3qYx7Sr7948iH7uzyVNyEn8QrMnnKM0AKbl8+uUD0LI/aZxSguYwa+jBuR7mi2g= X-Received: by 2002:a05:690e:2556:b0:640:d3ef:3ff3 with SMTP id 956f58d0204a3-641e74cd39amr11546575d50.15.1763504959958; Tue, 18 Nov 2025 14:29:19 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Nick Sullivan Date: Tue, 18 Nov 2025 17:29:09 -0500 X-Gm-Features: AWmQ_bnEFN7xsvYvmg1b4TJ0t8VR6vakyrNS00adG4NoI8QfLPapj-tNXYRg0sc Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary="000000000000b2b3890643e5fea2" Message-ID-Hash: 5MFEORQ75YXX7432PTWK4CT4JEDMTQHP X-Message-ID-Hash: 5MFEORQ75YXX7432PTWK4CT4JEDMTQHP X-MailFrom: nicholas.sullivan@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-cfrg.irtf.org-0; header-match-cfrg.irtf.org-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: John Mattsson , "cfrg@ietf.org" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BCFRG=5D_Re=3A_I-D_Action=3A_draft-irtf-cfrg-pairing-friendly-cu?= =?utf-8?q?rves-12=2Etxt?= List-Id: Crypto Forum Research Group Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000b2b3890643e5fea2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFAM John Bradley w= rote: > 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=E2=80=AFAM, John Mattsson 40ericsson.com@dmarc.ietf.org> 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, "internet-drafts@ietf.org" > 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-1= 2.html > > A diff from the previous version is available at: > > https://author-tools.ietf.org/iddiff?url2=3Ddraft-irtf-cfrg-pairing-frien= dly-curves-12 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > > _______________________________________________ > CFRG mailing list -- cfrg@irtf.org > To unsubscribe send an email to cfrg-leave@irtf.org > > > _______________________________________________ > CFRG mailing list -- cfrg@irtf.org > To unsubscribe send an email to cfrg-leave@irtf.org > --000000000000b2b3890643e5fea2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi John^2,

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

If you missed it, Yumi gave a presentation at IETF 1= 24 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 h= elp with this effort. We think there's momentum to continue this work a= nd to get a draft to RGLC again, though it may require setting up an interi= m meeting between now and IETF 125 to tie everything up.

I'll st= art a thread by the end of the week to summarize the state of affairs. Ther= e are still open questions, so it would be great to capture them in that th= read so we can reach consensus on a strategy for moving forward on the topi= c of pairing-friendly curves.

Because many higher-level algorithms m= ay rely on the recommendations in this specification, it's important th= at we cover the topic in a way that considers
- how best to help IETF en= gineers understand the security considerations of protocols that use pairin= g-friendly curves
- the rationale behind which concrete parameter choice= s we list and produce test vectors for
- whether this draft is op= inionated about interfaces and abstractions around these primitives (mappin= g to h2c for example)

Nick

On Tue, Nov 18, 2025 at 10:06=E2=80=AFAM John Bradley <ve7jtb@ve7jtb.com> 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
Joh= n B.

=
On Nov 18, 2025, at 5:47=E2=80=AFAM, John Ma= ttsson <john.mattsson=3D40ericsson.com@dmarc.ietf.org> 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.
- =C2=A0The ZCash serialization format

I don't think "Selection of Pairing-Friendly Curves" includin= g what is standardized in other SDO is essential. I think BN462 could be re= moved. less is more. Correctly if I am wrong but my understanding is that B= LS12_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, "internet-drafts@ietf.org" <internet-drafts@ietf.org> w= rote:

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= .

=C2=A0=C2=A0 Title:=C2=A0=C2=A0 Pairing-Friendly Curves
=C2=A0=C2=A0 Authors: Yumi Sakemi
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0Satoru Kanno
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0Riad S. Wahby
=C2=A0=C2=A0 Name:=C2=A0=C2=A0=C2=A0=C2=A0draft-irtf-cfrg-pairing-frie= ndly-curves-12.txt
=C2=A0=C2=A0 Pages:=C2=A0=C2=A0 54
=C2=A0=C2=A0 Dates:=C2=A0=C2=A0 2025-11-02

Abstract:

=C2=A0=C2=A0 Pairing-based cryptography, a subfield of elliptic curve<= /div>
=C2=A0=C2=A0 cryptography, has received attention due to its flexible = and
=C2=A0=C2=A0 practical functionality.=C2=A0=C2=A0Pairings are special = maps defined using
=C2=A0=C2=A0 elliptic curves and it can be applied to construct severa= l
=C2=A0=C2=A0 cryptographic protocols such as identity-based encryption= , attribute-
=C2=A0=C2=A0 based encryption, and so on.=C2=A0=C2=A0At CRYPTO 2016, K= im and Barbulescu
=C2=A0=C2=A0 proposed an efficient number field sieve algorithm named = exTNFS for
=C2=A0=C2=A0 the discrete logarithm problem in a finite field.=C2=A0= =C2=A0Several types of
=C2=A0=C2=A0 pairing-friendly curves such as Barreto-Naehrig curves ar= e affected
=C2=A0=C2=A0 by the attack.=C2=A0=C2=A0In particular, a Barreto-Naehri= g curve with a 254-bit
=C2=A0=C2=A0 characteristic was adopted by a lot of cryptographic libr= aries as a
=C2=A0=C2=A0 parameter of 128-bit security, however, it ensures no mor= e than the
=C2=A0=C2=A0 100-bit security level due to the effect of the attack.= =C2=A0=C2=A0In this
=C2=A0=C2=A0 memo, we list the security levels of certain pairing-frie= ndly curves,
=C2=A0=C2=A0 and motivate our choices of curves.=C2=A0=C2=A0First, we = summarize the adoption
=C2=A0=C2=A0 status of pairing-friendly curves in standards, libraries= and
=C2=A0=C2=A0 applications, and classify them in the 128-bit, 192-bit, = and 256-bit
=C2=A0=C2=A0 security levels.=C2=A0=C2=A0Then, from the viewpoints of = "security" and "widely
=C2=A0=C2=A0 used", we select the recommended pairing-friendly cu= rves considering
=C2=A0=C2=A0 exTNFS.

The IETF datatracker status page for this Internet-Draft is:

There is also an HTML version available at:

A diff from the previous version is available at:

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts



_______________________________________________
CFRG mailing list -- cfrg@irtf.org
To uns= ubscribe send an email to cfrg-leave@irtf.org

_______________________________________________
CFRG mailing list -- cfr= g@irtf.org
To unsubscribe send an email to cfrg-leave@irtf.org
--000000000000b2b3890643e5fea2--