ペアリング曲線標準化が再始動 – Ethereumも採用するBLS12-381の行方 / 開発者向けブログ・イベント

この記事は GMOインターネットグループ Advent Calendar 2025 20日目の記事です。
こんにちは、暗号のおねえさんことGMOインターネットグループエキスパートの酒見(さけみ）です。
現在のミッションとして、安心・安全・便利なインターネットの世界を目指して、先端の暗号技術の研究開発支援や標準化活動支援に取り組んでいます。
今回の記事では、その活動の中でも今年一番、事態が動いた！？IETFでのペアリング標準化活動の取り組みについてご紹介したいと思います！

はじめに

ペアリング（pairing）は、BLS署名や属性ベース暗号（ABE）、IDベース暗号（IBE）などの暗号方式を成立させるための基盤技術です。
そして IRTF/CFRG では、これらで利用される pairing-friendly curves（ペアリング向け曲線パラメータ）を、セキュリティレベルや採用状況と合わせて整理し、推奨を提示するための文書(internet-draft、イメージとしてはRFCの赤ちゃん) をRFC化すべきアイテムのひとつとして取り扱っています。

この活動は、他のCFRGメンバーと文書の方向性のコンセンサスがなかなかとれず、2020年ごろから長らく停滞をしておりました。。。
しかし、ペアリング曲線のRFCは必要であり、再開をリクエストいただく声を多数をいただきまして、この度、2025年11月にカナダ、モントリオールで開催されたIETF124の会合にて、再始動することを発表しました。

本記事では、そのinternet-draftの活動紹介にあたり、(1)ペアリングの要点、(2)ペアリングで“実用上”何が変わるか、(3)代表的な具体例、(4)なぜ曲線の標準化が重要か、(5)MLでの議論の現在地を、事実ベースで整理していきます。

IETF / IRTF / CFRGとは？

IETF：インターネット技術の標準化（RFCを中心に策定）
IRTF：研究寄りの活動（研究成果の文書化など）
CFRG（Crypto Forum Research Group）：IRTF配下で暗号を扱う研究グループ

CFRG（Crypto Forum Research Group）とは

仕様そのものだけでなく、実装・相互運用・安全性評価・パラメータ選定といった「現場で事故りやすい論点」が集まりやすい場です。たとえば Hashing to Elliptic Curves（RFC 9380）はCFRG成果物としてDatatracker上でも明記されています。

ペアリング暗号とは？

ペアリング暗号は、通常の公開鍵暗号（RSA/ECDSA/ECDHなど）だけで同じ目的を達成しようとすると、そもそも達成できない/設計が複雑になりやすい／サイズや計算量が大きくなりやすい機能を、比較的シンプルに実現しやすくする暗号技術です。
ポイントは、暗号の部品として「特別な写像（ペアリング）」を使えることで、プロトコル設計上の自由度が増える点にあります。
(ここでは、数式などを用いた詳細説明は省略しております)

その結果、ペアリングを用いると次のような性質を“実用的に”狙えるようになります。

多数を1つにまとめる（集約・圧縮）

多数の署名や同意を、よりコンパクトな形で表現できる（例：BLS署名の集約）。

「誰が復号できるか」を“証明書”ではなく“ルール”で表現しやすい（ポリシー暗号）

メールアドレス等の識別子を公開鍵として扱う（IBE）、属性（役職・所属など）を満たす人だけ復号できる（ABE）といった設計が取りやすい。

（位置づけ）証明系の効率化につながる土台

ゼロ知識証明などでペアリングを使う方式がある

以下では、この「何が嬉しいのか」を押さえた上で、代表的な具体例（BLS/IBE/ABE）に進みます。

ペアリングでなにが実現されるのか？（代表例）

1）BLS署名（集約できる署名）

CFRGのBLS署名ドラフトは、BLSを「aggregation properties（集約性）を持つデジタル署名」と説明しています。複数署名をまとめた“集約署名”を作れること自体が、用途を押し広げます。
実利用の例（仕様ベースで確認できるもの）として、EthereumのConsensus Specsでは「Validator public keysはBLS12-381曲線上の点である」ことが明記されています。
また同Specs内で「BLS12-381署名（proof of possession）」が登場し、BLS署名が前提で議論されていることも確認できます。

2) IBE（IDベース暗号）

IBEは「メールアドレスのような識別子」を公開鍵として扱う設計が可能になり、証明書配布前提の運用と異なる鍵配布モデルを組めます。
事例として、Common CriteriaのSecurity Target文書内で、Voltage SecureMail Suiteが「受信者の IBE 公開鍵（＝グローバルに一意な email address）」を用いて鍵配送を行う、という記述が確認できます。

3) ABE（属性ベース暗号）

ABEは「利用者の属性に応じたアクセス制御」を暗号レイヤで表現できることが特徴です。
公開情報として、NTT DATAとUTS（シドニー工科大学）が、UTS Vaultにおいて「属性に応じたアクセス制御ができるABE技術を活用したソリューションの商用利用に合意」した旨をリリースで明記しています。

実際にどのようなビジネス領域で利用されているのか？

分散システム／ブロックチェーン（合意形成・大量署名）

BLS署名の集約性が設計上効く。EthereumのConsensus SpecsでBLS12-381前提が確認できます。

メール／エンタープライズ暗号化（鍵配布モデル）

IBEを使った製品仕様が文書で確認できる（例：Voltage SecureMail SuiteのSecurity Target）。

機密データ共有／データガバナンス（属性で復号）

ABEの商用利用合意が公式リリースで確認できる（例：NTT DATA × UTS Vault）。

なぜ“曲線”を標準化するのか？

いちばん影響が大きいのは「弱いパラメータを選んで本番に載せる」事故
Pairing-Friendly Curvesドラフトの目的が、まさに「安全性レベル整理＋推奨の提示」
ペアリング暗号自体の安全性評価が非常に複雑・困難

この3点です。以下に詳細を説明していきます。

いちばん影響が大きいのは「弱いパラメータを選んで本番に載せる」事故

暗号は後から差し替えが効きにくく、移行時に鍵・署名・互換性・データ再暗号化などが連鎖しがちです。そのため、 “曲線・パラメータ選定を個人の勘にしない”ことに価値があります。

Pairing-Friendly Curvesドラフトの目的が、まさに「安全性レベル整理＋推奨の提示」

ドラフトは、(a)国際標準・ライブラリ・アプリでの採用状況を整理し、(b) 128/192/256-bitのセキュリティレベルに分類し、(c)「security」「widely used」の観点から各レベルの曲線を選定する、と概要で述べています。
実務的にはこれが「選定ミスを構造的に減らすための共通根拠」になります。

ペアリング暗号自体の安全性評価が非常に複雑・困難

現行の楕円曲線暗号やRSAは、楕円曲線上の離散対数問題や素因数分解問題の難しさが安全性の根拠となっています。
一方、ペアリング暗号では、複数の数学的問題が絡み合って安全性が成り立っており、評価が難しいという背景があります。
とくに、今回のinternet-draft執筆のきっかけとなったKimらの攻撃により、ペアリング暗号の安全性評価はさらに難しくなりました。そのため、安易にパラメータを選んでしまうと、システムの安全性を脅かしてしまうリスクがあります。

CFRGのMLで議論されている Pairing-friendly Curves の標準化動向

IETF 124のプレゼン後、CFRG ChairのNick Sullivanが「更新版を出す／interimを開く前に、合意しておきたい未決論点」をMLで列挙し、意見募集を開始しています。

文書のスコープと構成
曲線の選定
インタフェース／関連プリミティブ
シリアライズ（符号化）
フレーミングと実用性

列挙された論点は、実装者が事故を避けるうえで“そのまま重要ポイント”です。

文書のスコープと構成

曲線パラメータ＋テストベクタ中心に寄せるか、インタフェース指針・シリアライズ形式・チュートリアル要素まで含めるか
背景説明は付録／別文書へ分離するか（タイトルや位置づけも見直すか）

曲線の選定

「BLS12-381 + BLS24を1つ + BLS48を1つ（=128/192/256-bit狙い）へ絞る」案
BN曲線を外す案や、BLS用途だけ対象にするか、ZKPやIBE等も対象にするか

インタフェース／関連プリミティブ

mapping to G1/G2、hash-to-curve参照など、期待する抽象化やインタフェースを文書で書くか
RFC 9380など他仕様に委ねて中立にするか
最小ペアリングAPI（関数シグネチャ／domain separationガイダンス）まで踏み込むか

フレーミングと実用性

Kimらの攻撃であるexTNFSなどを踏まえた安全性前提、subgroup checkなど実装リスク、適用可能なプロトコルクラスを明示すべきか
テストベクタに中間値や複数エンコーディング結果も含めるべきか

CFRGでのNext Actionとしては、MLで意見を集めた後、GitHub issue化し、必要なら短いinterimを検討する、という流れが計画されています。

おわりに

ペアリング暗号は「高度で難しい話」に見えますが、実装者視点では結局 “安全なパラメータ選定” が勝負です。CFRGの Pairing-Friendly Curves は、曲線の推奨セットを作ろうとしていて、まさに今「何を文書に含めるべきか」「何を推奨し、何を外すか」がMLで具体的に詰められています。

安全なインターネットの世界を目指して、引き続き、Pairing-Friendly Curvesの標準化に取り組んでいきたいと思いますので、応援いただけるとうれしいです！