8
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【速報】IETF124 CFRG セッション1 参加報告 - ペアリング曲線とBLS署名の再始動に注目

Posted at

おはようございます!
時差ボケが酷くていつ寝落ちするかわからないという爆弾を抱えた男 GMOコネクトでCTOしている菅野(かんの)こと、さとかん です。

今回は、CFRGに関する参加報告を書きます!

はじめに

IETF124がカナダ・モントリオールで開催され、2025年11月3日(月)にCrypto Forum Research Group (CFRG)のセッション1が行われました。本記事では、セッションで議論された主要トピックについて報告しちゃいます。

釈迦に説法かもしれませんが、CFRGはIRTF(Internet Research Task Force)に属する研究グループで、長期的な暗号技術の研究とプロトコル設計者への助言を目的としています。IETFが標準化に焦点を当てるのに対し、IRTFはより研究指向のアプローチを取っています。

セッション概要

  • 日時: 2025年11月3日(月)12:00-13:00 (UTC-5)
  • 議長: Nick Sullivan、Alexey Melnikov、Stanislav Smyshlyaev
  • 主要トピック: VDAF、CPace、Pairing-Friendly Curves、BLS Signatures
  • 参考情報

エグゼクティブサマリー

今回のセッションで特に注目すべきは、期限切れとなっていたPairing-Friendly CurvesとBLS Signaturesドラフトの再始動です。これらの仕様は相互に依存しており、BBS署名スキームやEU EIDASでの採用検討など、他の標準化推進のボトルネックとなっている状況だったので大きな動きとなっております。
なお、Pairing-Friendly Curvesの標準化しているのはGMOコネクトであり、ワイも著者として貢献していきます。
第一著者な暗号のおねぇさんから本件は詳しい記事が出るんじゃないかと思います。

また、VDAFは最終段階のRGLC前に重要な最適化を取り込む方針が示され、CPaceはダブリン開催以降大きな変更がなく、RGLC開始の準備が整ったことが報告されました。

1. 運営報告と最近のRFC発行

Chairからの前回会合からのアップデート等がありました。
詳しくは、Chair's slideをご確認ください。

新規RFC(2024年7月以降)

以下の3つのRFCが発行されました:

  • RFC 9858: Additional Parameter Sets for HSS/LMS Hash-Based Signatures
  • RFC 9861: KangarooTwelve and TurboSHAKE
  • RFC 9807: The OPAQUE Augmented Password-Authenticated Key Exchange (aPAKE) Protocol

新規採択ドラフト

ゼロ知識証明分野での取り組みとして、以下の2つのドラフトが採択されました:

  • draft-irtf-cfrg-fiat-shamir: Fiat-Shamir Transformation
  • draft-irtf-cfrg-sigma-protocols: Interactive Sigma Proofs

ハイブリッドKEM中間会議

前回のIETFと今回の間に、ハイブリッドKEMs(鍵カプセル化メカニズム)に関する中間会議が開催され、29名が参加しました。木曜日のCFRGセッション2でフォローアップ議論が予定されています。

2. VDAF: プライバシー保護データ集計の最適化

背景とユースケース

Christopher Patton氏より、draft-irtf-cfrg-vdafの更新報告がありました。

VDAF (Verifiable Distributed Aggregation Functions) は、企業がユーザーから必要以上のデータを収集する問題に対し、セキュアな集計を実現する軽量マルチパーティ計算プロトコルです。

主なユースケース:

  • ブラウザテレメトリー
  • COVID-19接触追跡
  • 広告コンバージョン測定
  • 連合学習(Federated Machine Learning)

VDAFの2つのアプローチ

  1. Prio3 VDAF: 一般的なメトリクス向け

    • プライバシー: 加法秘密分散(Additive Secret Sharing)
    • 検証: 完全線形証明(Fully Linear Proof: FLP)
  2. Poplar1 VDAF: ヘビーヒッター検出向け

    • プライバシー: 分散点関数(Distributed Point Function: DPF)
    • 検証: 算術的スケッチ(Arithmetic Sketching)

RGLC前の重要な最適化

RGLCに進む前に、2つの重要な改善が提案されています:

Issue #549: FLP範囲チェックの改善

現在、非べき乗数の範囲チェック($x \in [0, m)$ where $m$ is not a power of 2)は通信コストが高くなる問題があります。

改善案: ビット分解を工夫することで、べき乗範囲チェックと同じ通信コストで任意の範囲チェックを実装可能に。これによりSumVecなどのVDAFバリアントの有用性が大幅に向上します。

Issue #574: ラグランジュ基底による高速化

改善案: Proverが証明に含める多項式をモノミアル基底ではなくラグランジュ基底(Lagrange basis) で表現することで:

  • NTT(高速フーリエ変換の一種)操作を回避
  • 証明時間が最大1.5倍(50%増)高速化

議論と方針

Nick Sullivan(chair): これらの変更に対するCrypto review panelのレビューは合理的で迅速に行えるはず。

Tim Geoghegan: これらの変更を取り込むべき。その後RGLCに進み、将来さらに良いアイデアが出てもプロトコルを改訂できる。

結論: もう一度ドラフトを改訂し、Crypto review panelの差分レビューを経てRGLCに進む方針。

3. CPace: Universally Composableなバランス型PAKE

現状報告

Björn Haase氏より、draft-irtf-cfrg-cpace-15の報告がありました。

CPace (Balanced Composable PAKE) は、パスワードベースの認証鍵交換プロトコルです。

バージョン13以降の主な変更

文書の簡素化:

  • 「ネットワーク表現」への参照を削除
  • 統合ガイダンスセクションを追加(TLS等の上位プロトコルへの統合方法)

セキュリティ分析の強化:

  • 新しい論文(BGHJ24)の結果を統合
  • セッションID(sid)が事前に確立されていない場合でも、CPaceと並行して一意のセッションIDを計算可能であることを証明
  • UC(Universally Composable)セキュリティをゲームベース分析に加えてUC分析でも独立確認

テストベクトル: 人間が読める形式と埋め込みJSONバージョンの両方を提供

次のステップ

著者らはドラフトが安定したと判断し、IETF 124直後のRGLC開始を議長に要請しました。

セッション中、聴衆からの反対意見はありませんでした。

4. Pairing-Friendly Curves: 再始動の背景と課題

重要性とセキュリティ問題

暗号のおねぇさん(GMOコネクト)より、期限切れとなっていたdraft-irtf-cfrg-pairing-friendly-curvesの再始動について報告がありました。

ペアリングは以下の高度な暗号プリミティブを実現する基盤技術です:

  • BLS署名
  • zk-SNARKs(ゼロ知識証明)
  • IBE(Identity-Based Encryption)

セキュリティ問題: 2016年のKimらによるexTNFS攻撃により、BN254のような曲線のセキュリティレベルが低下したにもかかわらず、セキュリティが不十分なレガシーパラメータが依然として使用されています。

ドラフトが停滞した理由

パラメータ自体には幅広い合意があったものの、ドキュメントのスコープについて意見の相違がありました:

  • 著者の立場: パラメータの標準化に焦点を当てたい
  • 一部レビュアーの要求: ペアリングの背景全体を説明する教科書レベルのチュートリアルを追加すべき

再始動の動機

このドラフトはBBS署名スキームなど他の仕様のボトルネックとなっています。

提案:

  • パラメータ標準化に不可欠な情報のみに焦点を絞る
  • 教科書レベルの説明が必要なら、別文書としてボランティアを募集

Rich Salz: 期限切れになった理由の説明に対する感謝の言葉やChristopher Patton: BLSのI-Dがこれを参照している(informative reference)というコメントがあり、問題なく発表を終えた感触です。

5. BLS Signatures: エコシステム全体の前進

背景と依存関係

John Bradley氏より、期限切れとなっているdraft-irtf-cfrg-bls-signatureの再開について報告がありました。

BLS署名スキームは、以下の仕様の基盤となっています:

  • CFRG: BBS署名スキーム
  • JOSE WG: JSON Web Proof

技術的更新

BLS12曲線に適用可能な、より高速なサブグループチェックへの参照を追加(2020年9月に特許が期限切れ)。

活発な活動と採用検討

  1. EU EIDAS: プライバシーとスケーラビリティのソリューションとしてBBS署名を検討
  2. NIST: Multi-Party Threshold ワークショップでBLS署名ベースの提案が予定

中間会議(Interim)提案とコミュニティの反応

提案: 関連するCFRG仕様全体(Pairing-Friendly Curves、BLS、BBSなど)をパッケージとして進めるための**中間会議(Interim)**を開催。

議論の焦点: ペアリング曲線ドラフトのスコープについて

  • パラメータのみで十分か?
  • 詳細な説明が必要か?

コミュニティの反応:

  • Michael Jones (JOSE): JOSEがこれを必要としている、ぜひ実現してほしい
  • Michele Orr: 標準化されたものが必要
  • Christopher Patton: 短期的にでも(PQC時代を見据えて)必要
  • Hannes Tschofenig: パラメータを単に述べる以上の説明が必要
  • Brent Zudel: パラメータで十分だと思う

まとめと今後の展望

主要な決定事項

  1. VDAF: 重要な最適化(範囲チェック改善、ラグランジュ基底)を取り込んでからRGLC
  2. CPace: IETF 124直後にRGLC開始予定
  3. Pairing-Friendly Curves + BLS署名: 中間会議を開催し、パッケージとして前進させる方針

依存関係の連鎖

Pairing-Friendly Curves
    ↓ (informative reference)
BLS Signatures
    ↓ (依存)
BBS Signatures → JSON Web Proof (JOSE WG)
                 ↓
              EU EIDAS採用検討

このように、Pairing-Friendly CurvesとBLS署名の標準化が、エコシステム全体の前進に不可欠であることが明確になりました。

所感

今回のセッションでは、技術的成熟度と実装ニーズのバランスを取りながら標準化を進める難しさが浮き彫りになりました。特にPairing-Friendly Curvesの「教科書的説明 vs パラメータのみ」という議論は、RFCドキュメントのスコープをどう定義すべきかという本質的な問題を提起しています。

一方で、EU EIDASやNISTワークショップなど、実世界での採用が目前に迫っており、標準化の加速が求められています。中間会議での建設的な議論に期待したいと思います。


注記: アジェンダに掲載されていたArmando Faz氏による「Polynomial Evaluation in the Lagrange basis」のプレゼンテーションは、セッション1ではスキップされ、木曜日のセッション2に持ち越されました。


最後に、GMOコネクトでは研究開発や国際標準化に関する支援や技術検証をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。
一緒に働きたい人も気軽にコンタクトを取ってください!

お問合せ: https://gmo-connect.jp/contactus/

8
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
8
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?