要約

  • CFRGは2026年9月7日、draft-irtf-cfrg-pairing-friendly-curves第14版を公開した。IRTFの研究グループによる現役のInternet-Draftで、Informationalとしての公開を想定している。RFCでもIETF標準でもない。
  • 第14版はBLS12-381とBLS48-581の点について規範的なシリアライズ／デシリアライズ手順を示し、この2曲線とBN462のスカラー手順も定める。正準座標、曲線上の点か、所定の部分群に属するかを検査し、群要素またはINVALIDを返す。
  • 共通デコード後にも三つの判断が残る。呼び出し側は圧縮点・非圧縮点・両方のどれを受け入れるか、単位元を許すか、ゼロスカラーを許すかを明記する必要がある。
  • 第13版にあった単位元拒否の一般的な推奨既定値は削除され、ゼロスカラーの扱いは単位元から切り離された。BN462の点形式は、実装慣行が収束していないため規範化されていない。
  • Daniel Kadeは、下流仕様が七項目の受け入れプロファイルを公開するよう提案する。これは本稿の分析であり、第14版やCFRGの要求ではない。

数学的に正しいことと、メッセージとして許されること

暗号仕様で「検証」という語を使うとき、二つの仕事が重なりやすい。一つは、入力の長さとメタデータが正しく、座標が正準形であり、復元した点が狙った曲線と部分群に属するかを確かめる仕事だ。もう一つは、その有効な値を特定の鍵、署名、証明、メッセージ欄に置いてよいかを判断する仕事である。

第14版は前者を精密にした。点のデシリアライズは群要素かINVALIDのどちらかを返す。体の法以上の座標を法で縮約して受け入れるのではなく拒否し、同じ座標に複数のバイト表現が生じるのを防ぐ。曲線式と部分群を検査し、符号化長が同じ型であっても曲線の領域を混同しない。

スカラーも、符号化された整数がスカラー体の位数未満でなければならない。ゼロには正準な表現がある。しかし、表現できることは、プロトコルのその欄で許されることを意味しない。汎用デコーダーは、入力が秘密鍵なのか係数なのか、あるいはゼロが意味を持つ中間値なのかを知らない。

このため、二つの実装が共通手順を正しく実装していても、呼び出し側の規則が不明なら相互運用できない。共通層が同じ数学的対象を返した後、一方だけが拒否する場合も、両方が受理しながら異なる元のバイト列を別物として保存する場合もある。

三つの判断は一つの「厳格モード」ではない

第一は点の形式だ。第14版は、圧縮形式のみ、非圧縮形式のみ、または両方を受理するかを呼び出し側プロトコルが述べるよう求める。両方を許せば、同じ数学的な点に二つの正しいバイト列が生じる。受信バイトをそのままハッシュし、署名し、比較し、データベースやキャッシュのキーにすれば、表現の違いがアプリケーション状態の違いになる。

第二は単位元だ。構成によっては拒否すべき固有の理由がある。BLS署名案のKeyValidateは単位元を排除しており、無効なゼロ秘密鍵と単位元署名の問題に結び付く。一方、別の代数的な構成では単位元が正当な役割を持ち得る。第14版が普遍的な既定値を置かないのは、答えが構成の意味と脅威モデルに依存するからだ。

第三はゼロスカラーで、単位元とは独立した判断である。第13版は単位元拒否を推奨される既定値とし、ゼロの扱いも同じプロトコル依存方針に従うとしていた。第14版はこの結び付きを解いた。RFC 9591では、要素のデシリアライズは単位元を拒否する一方、スカラーのデシリアライズに同様のゼロ拒否は加えられていない。二つを分ける実例である。

したがって、圧縮形式だけを受け入れ、単位元を拒否し、特定の欄ではゼロを許す設計も成立する。二形式を受け入れ、ある演算では単位元を使い、ゼロスカラーは拒否する設計もあり得る。三つをライブラリーの一個のスイッチにまとめれば、ライブラリーがプロトコルの意味を代行してしまう。

BN462は共通仕様の境界を示す

第14版はBLS12-381とBLS48-581の点形式を定めるが、BN462の点形式は定めない。BN462の基礎体の法は462ビットを使う。58バイトは464ビットなので余るのは2ビットだけだが、共通の圧縮形式は三つのメタデータを格納する必要がある。

参考情報の付録は、既存ソフトウェアに互換性のない方式があると整理する。SEC1風の型バイトを置く方式、フラグ専用のバイトを置く方式、同じメタデータ規則を持たないパック形式などだ。著者らが調べた仕様はBN462点の符号化を要求しておらず、慣行も収束していない。そのため、第14版はどれか一方式を規範として選ばなかった。

これはBN462の実装が存在しないという意味でも、列挙された方式が危険だという判定でも、既存実装の全面変更命令でもない。意味するところは限定的だ。BN462点を通信路に載せるプロトコルは、第14版への参照だけでは足りず、外部の符号化仕様を特定するか、自ら完全な規則を定義しなければならない。

局所判断を既定値の陰に置かない

開発記録には共通化の理由が残る。CFRGリポジトリのissue 74では、関連文書が別々に定義を複製して不一致を生むより、一つの権威あるシリアライズ定義を求める声が出た。pull request 108は、名前付き手順、部分群検査、呼び出し側の選択、テストベクトルなどの改稿を第14版に取り込んだ。CFRGメーリングリストでは、依存文書の著者にも新章が通知された。BBS署名案とCOSEのBLS鍵表現案は、依存関係が実際にあることを示す。

小さく明確な共通層は数学表現のずれを減らせる。しかし、各アプリケーションの意味まで中央で決めるべきではない。最小の初期仕様と局所的な将来判断を両立させる条件は、局所判断が観測できることだ。ライブラリーの既定値にしか存在しない選択は、分権ではなく、文書化されていない分岐になる。

そこで私は、呼び出し側仕様が七項目の「受け入れプロファイル」を公開することを提案する。参照する曲線文書の版、曲線、受け入れる点形式、単位元の規則、ゼロスカラーの規則、部分群検証の経路、BN462点を使う場合の外部符号化参照である。同じ項目を相互運用試験にも載せれば、実装間の差をコード投入前に比較できる。

この名称と七項目はDaniel Kadeの提案であり、第14版に書かれた要件ではない。目的は局所判断を統一することではなく、誰がどの版に対して何を決めたかを明らかにすることだ。

情報源