要約

  • RFC 9106 は Argon2 1.3 の入力、パラメータ選定、テストベクトルを定めるが、個別の認証サービスの処理能力までは認証しない。
  • 運用側は一回分のメモリと遅延に加え、同時実行数、キュー、過負荷時の挙動、旧設定の残存率を別々の証拠として残す必要がある。

認証サーバーが一件の要求を受け取る。保存されたレコードには Argon2id、version 19、固有の salt、64 MiB、三回の pass、四本の lane が記録されている。計算は成功する。それでも、サービスを左右する問いには答えていない。同じ検証が数百件重なったとき、メモリと時間を誰が負担するのか。

RFC 9106 のパラメータ選定手順は、この境界を隠していない。まず一回の呼び出しに割ける最大メモリを決め、次に許容時間を決め、pass 数を調整する。最初の一回でも遅すぎればメモリを下げる。安全性は名称から自動的に得られるものではなく、運用資源の枠内で選ばれる。

その枠は計算そのものに結び付く。password P、salt S、並列度 p、tag 長、メモリ m、pass 数 t、version、type が初期ハッシュに入り、任意の secret と associated data も含められる。メモリは 1 KiB の block に分けられ、p 本の lane に配置される。各 lane は slice の中では並行して進めるが、slice の境界で同期する。追加 pass は行列を再訪する。「Argon2id を使っている」だけでは、主要な運用コストが欠けている。

仕様はパスワードごとに固有の 16 byte salt を推奨する。salt は同じパスワードの結果が同一になることを防ぐが、秘密ではなく、推測一回の仕事量を決める値でもない。検証器は各レコードの正確な version と設定を保持しなければならない。

二つの推奨値はトレードオフを可視化する。第一推奨は 2 GiB、pass 1、lane 4。メモリ制約下の第二推奨は 64 MiB、pass 3、lane 4 である。文書には 2 GHz CPU を前提にした例もあり、四 core、八 lane、4 GiB、0.5 秒のバックエンド認証が挙げられる。これは条件付きの参照点であり、仮想マシン、container、allocator、NUMA、メモリ帯域、実サービスの裾の遅延を保証しない。

テストベクトルが証明する範囲はさらに限定される。32 KiB、三 pass、四 lane といった固定入力で、中間 block と最終 tag が一致するかを確かめるものだ。一致すれば計算の互換性は確認できる。しかし、resident memory のピーク、キャンセル、memory wiping、scheduler の干渉、queue の成長、割り当て失敗時の処理は分からない。

単一呼び出しの設定を fleet の結論に拡張するところで、誤解が生じる。64 MiB に同時呼び出し数を掛けた値は計画上の境界にすぎず、観測値ではない。library の overhead、allocator の再利用、memory bandwidth が実測を動かす。限界で queue に入れるのか、拒否するのか、rate limit するのか、timeout させるのか、fail closed にするのかもサービス側の決定である。安い設定への無言の fallback は安全性の主張を変え、process の枯渇は防御コストを可用性攻撃に変える。

移行も別の測定対象だ。NIST は scheme と cost factor をパスワードごとに保存し、計算能力の向上に合わせて引き上げられるよう求める。しかし、新しい既定値を導入しても、既存アカウントが移行済みとは限らない。変更後にログインした利用者だけが再ハッシュされるなら、古い設定の人口は長く残る。見るべきものは設定組み合わせの分布、再ハッシュの trigger、失敗した upgrade、残存レコードである。

攻撃コストの言い方にも上限がある。memory-hard function は推測の資源負担を増やし、時間と空間の trade-off を攻撃者に課す。だが password の分布、漏えい範囲、攻撃機材、電力価格、account の価値は分からない。RFC 9106 は IRTF stream の Informational 文書であり、Standards Track ではない。研究成果が導入に適さない場合もあると自ら述べる。これはアルゴリズムの精密な仕様であって、観測していないシステムへの証明書ではない。

RFC 9807 との違いもここにある。OPAQUE では client-side KSF、パスワード非開示、OPRF seed の管理、record migration が中心になる。本稿は通常の server-side verifier が salt、memory、pass、lane を多数の同時呼び出しとして支払えるかを扱う。前者はプロトコルと鍵管理の地図、後者は容量と証拠の台帳である。

運用記録には、type、version、salt policy、m、t、p、tag length、optional secret、library と hardware class、cold/warm latency percentile、一回および process 全体の memory high-water mark、active calls、queue depth、rejection、timeout、cancellation、memory cleanup、CPU と帯域圧力、設定別の人口、rehash の成否、throttling と recovery を含めたい。ハッシュが成功したという事実は、その長い証拠列の出発点にすぎない。

出典

仕様と位置付け：RFC 9106、RFC Editor の記録、IETF Datatracker、Argon2 論文。設計史：Password Hashing Competition。検証器要件：NIST 認証器ガイダンスと NIST パスワード分析。隣接する境界：RFC 9807。分析枠組み：Minimum Initial Specification、Reality Layers、Running-Code Primacy。