要約

  • RFC 9591は、しきい値を満たす参加者のシェアを二つのラウンドで集め、グループ公開鍵で検証できる (R, z) 署名に集約する。
  • 最終署名には参加者一覧、個別シェア、コーディネーターの選択、業務承認は入らない。説明責任には認証済みセッション記録とローカル方針の判断が必要である。

外から見えるのは一人分の形だけ

FROSTの暗号的な利点は、秘密を一か所に集めずに、受け手には通常のSchnorr署名として扱える結果を出せることだ。対応する暗号スイートでは、Ed25519やEd448の検証器と互換の署名も生成できる。

たとえば五者中三者が必要な構成で署名が有効だったとする。外部検証者は、メッセージとグループ公開鍵に対して署名式が成立することを確認できる。どの三者だったかは分からない。各者が同じ契約書を読んだのか、単なるハッシュ値を渡されたのか、署名時点で役職が有効だったのかも分からない。

これは欠陥ではない。出力を既存の署名利用先へ接続しやすくするための性質である。しかし、暗号的成功をそのまま「取締役会の承認」などと表示すれば、圧縮された証拠に存在しない意味を足すことになる。

誰を呼ぶかはプロトコルの外側にある

参加者は固有のスカラー識別子、秘密シェア、公開検証シェアを持ち、共通のグループ公開鍵を使う。通常構成のコーディネーターは、今回の参加者を選び、ラウンド間のメッセージを運び、シェアを集約し、署名を公開する。

RFC 9591は、コーディネーターと署名者集合が外部で選ばれると明記する。単一コーディネーターを置かず、全員が相互通信する構成も可能だ。それでも、参加資格、しきい値、対象メッセージ、公開条件を決めるアプリケーション層は残る。

暗号上の識別子は人事台帳ではない。本人、職務、委任範囲、有効期間、失効状態は別の台帳で結び付ける必要がある。人が交代しても識別子や公開シェアが自動で無効になるわけではない。

第一ラウンドは使い捨て状態を作る

各参加者は二つの秘密nonceと対応する公開コミットメントを生成する。第二ラウンドでは、メッセージと全参加者の順序付きコミットメント一覧を受け取る。グループ公開鍵、メッセージ、一覧、個別識別子から拘束係数を計算し、署名シェアを返す。

nonceは一回限りである。RFCは再利用を禁じ、sign 後の削除を求める。再利用は参加者の秘密シェアを完全に回収する攻撃につながり得る。バックアップから古いnonce状態を戻す運用は、復旧成功と鍵安全を逆方向へ動かし得る。

集合の連続性も重要だ。RFCは、計算量を減らす一つの最適化を推奨しない。第一ラウンドを始めた集合と第二ラウンドで出力した集合が同じだという保証を失うからである。速度の数字だけでは、失われる監査性を評価できない。

集約後の二つの値から名簿は戻らない

コーディネーターはシェアを加算し、R と z を出す。標準の署名符号化に、参加者識別子、しきい値、コミットメント、個別シェア、承認理由は含まれない。後から署名を解析しても、それらは再生できない。

集約前なら、各シェアを個別公開鍵、コミットメント、全一覧、メッセージ、グループ鍵に照らして検証できる。不正シェアの送信者を特定するには、さらに通信路の認証が必要だ。数学上の参加者番号とネットワーク上の送信主体を結ぶのは暗号式ではなくチャネルである。

無応答は別問題だ。FROSTは参加拒否者を自動で特定しない。アプリケーションは要求の到達、期限、応答不在を記録できるが、それだけで故意や侵害を断定できない。処分や次回からの除外も仕様外の判断である。

正しいシェアでもメッセージの意味は承認しない

RFCは、参加者を任意メッセージの署名オラクルにしないよう、用途ごとの入力検証を推奨する。取引なら構文と利害関係者の意図、TLSならtranscript hashだけでなく元のハンドシェイクを確認する例が示される。

したがって、シェア検証は承認検証ではない。UIに示した金額、正規化後の署名対象、ローカル方針の結果、受け手が実行する命令が同一であることには別の結合が要る。現在の役職や利益相反も、秘密シェアの所持からは導けない。

証拠列は、資格名簿、今回の選定、認証済み通信、コミットメント、正確なメッセージ、各者の方針判断、シェア、集約、公開、下流効果へ続く。隣接する記録を一つの「署名済み」に潰すと、原因調査で必要な差が消える。

Informational RFCを導入済み証明にしない

RFC 9591はIRTFのInformational文書で、CFRGの合意を表す。IETF標準でも導入命令でもない。FROSTは離散対数問題に依存し、耐量子方式ではない。また、不正なシェアや不参加者がセッションを止め得るため、堅牢性を提供しない。ROASTはそのための別ラッパーである。

テストベクトル合格が証明するのは実装の一部だけだ。実運用には、乱数、nonceの永続状態、チャネル認証、メンバー変更、失敗時の扱い、監査保存、下流システムとの関連付けが要る。

Lu Hengの現実層という見方では、有効署名は実行可能な暗号事実である。「正式な機関が承認した」という表現は制度的事実であり、別の委任と記録を必要とする。FROSTの最小共通機構を尊重するとは、その境界を曖昧にしないことでもある。

情報源