要約

  • RFC 3385 は「32ビット・チェックサム」を不完全な説明として扱った。未検出誤りは生成多項式、保護ブロック長、誤り分布、実データの偏りでも変わる。
  • 著者らは、明示した偶発破損モデルの下で CRC32C を iSCSI の基本的な誤り検出に適した選択としたが、暗号学的完全性や普遍的な確率保証にはしなかった。

二つの検査欄が同じ四バイトを占め、トレース上ではどちらも乱数らしい値に見える。ところが、まとまったビット破損を一方は捕らえ、もう一方は通してしまう。見える幅は同じでも、保護の形は同じではない。RFC 3385 は、この幅の陰に隠れやすい差を選択前に計算可能にした。

文書は 2002 年 9 月、Informational RFC として公開された。iSCSI の誤り検出符号を選ぶため、未検出確率を推定することが目的だった。完成した iSCSI プロトコルでも、製品実装や普及の報告でもない。完全性らしい名称を決める前に、その名称が何を根拠にできるかを分析した文書である。

iSCSI は SCSI コマンドとストレージデータを IP ネットワークへ運んだ。見逃した転送誤りが有効な内容に見えたまま機器やファイルシステムへ届けば、損失は通信区間で終わらない。転送量も重要だった。文書はペタバイト規模を念頭に置き、少なくとも 8 KiB のブロックまで良好な検出性能を求めた。

先行する RFC 3347 は、TCP チェックサムだけでは十分な説明にならない理由を示していた。通過するビット誤りがあり得るうえ、プロキシやゲートウェイは TCP ストリームを終端し、iSCSI ヘッダーを再構築し、チェックサムも計算し直せる。SCSI データ、コマンド、状態を守るには、iSCSI 自身に属するダイジェスト境界が必要だった。

RFC 3385 は誤りを一種類の雑音として扱わない。騒がしいチャネルのバースト誤りと、低雑音チャネルの独立単一ビット誤りを別に分析した。メモリ故障、内部シリアル接続、ソフトウェア処理でも集中した破損が起こり得る。変化したビット数だけでなく、分布、持続時間、ブロック長が意味を持つ。

CRC は生成多項式を使い、情報ブロックに冗長ビットを付けて符号語を作る。受信語に誤りがあっても受理されるのは、その誤りパターン自体が符号語となる場合である。したがって最小距離と重み分布が、見逃す可能性のあるパターンを決める。32ビットという数字は冗長量であって、符号の幾何ではない。

短縮符号では差がさらに明確になる。同じ次数の生成多項式でも、実用ブロック長へ短縮したときの最小距離や重み分布は異なり得る。文書が引用した研究には、特定バーストで 32ビット多項式間に数桁の差が生じる例があった。幅だけなら同じ箱に入る符号が、必要な場面では別の性能を示す。

IEEE 802 の多項式と CRC32C は、ともに32ビット CRC である。CRC32C の生成子は 0x11EDC6F41 だった。この値は単なる実装注記ではない。どの誤り多項式が割り切れるかを変え、対象長における検出面を変える。

確率値には必ず仮定が付く。文書はバースト誤り率、独立ビット誤り率、バースト持続時間の分布を仮定し、固定時間のバーストが速度に応じて何ビットを覆うかを計算した。さらに 8 KiB の保護単位を置いた。チャネル、分布、ブロック、データを変えれば、結論も同じ境界には留まらない。

極端に小さい数値ほど切り離して引用されやすい。宣言したモデルでは CRC32C の未検出バースト確率に非常に低い上限が得られた。しかし、それは全ネットワークの実測値でも製品保証でもない。「この仮定でこの上限を得た」が正しい証拠形式であり、「どこでもほぼ失敗しない」ではない。

Fletcher と Adler との比較は別の教訓を与えた。分析した独立誤り条件では CRC は Fletcher より約12,000倍、Adler より約22,000倍良いと推定された。加算型チェックサムが見逃す短い連続バイトの例も示された。実データには偏りやホットスポットがあり、均一分布の仮定よりチェックサムが悪化し得る。

まとめ表には Fletcher32、Adler32、IEEE-802 CRC、CRC32C が並ぶ。全部32ビットなのに、最小距離の範囲とモデル化された未検出確率は異なった。著者らが CRC32C を良い基本選択とした理由は、保護水準、偏ったデータへの相対的な鈍感さ、長いブロックを扱う力の組み合わせだった。

コストも比較された。引用された合成では CRC32C は CCITT-CRC32 より多くのセルを使った。ただし、代表的な百万セルの小型チップに対する CRC 回路の比率は一パーセント未満だった。コストを消したのではなく、保護利得と同じ尺度に置いたのである。

相互運用には多項式名以上が必要だった。文書は直列と32ビット並列のハードウェア例を示し、ソフトウェアでは入力と状態を索引にする表が一般的だと述べた。ビット順、初期化、補数、パディング、剰余の配置まで一致しなければ、双方が CRC32C と呼んでも同じ値にはならない。

CRC の線形性は増分更新を可能にする。中間ノードが対象ヘッダーを変更するとき、データ全体を読み直さず差分から CRC を更新できる。最終ターゲットはヘッダー、データ、CRC をまとめて検証し、多段経路で混入した望まない変化も対象にできる。これは効率と範囲の性質であり、中間ノードを認証する性質ではない。

後の統合 iSCSI 仕様 RFC 7143 は運用契約を明確にした。HeaderDigest と DataDigest の既定値は None だが、すべてのイニシエータとターゲットは CRC32C と None を実装しなければならない。ダイジェストが合意されれば Full Feature Phase の PDU に使われる。仕様は非暗号学的検査と明記する。

ここでも事実は分かれる。実装が CRC32C を持つこと、セッションが提示すること、相手が選ぶこと、PDU が検証を通ること、保護が iSCSI 境界の外まで連続することは別々である。対応済みという表示から、全接続で有効だとは言えない。

セキュリティ境界は明瞭だった。攻撃者がデータを変更できるなら、新しいデータに合う検出値も変更できる。CRC は偶発変化を検出するが、送信者を認証せず、権限を結び付けず、悪意ある改変を防がない。通過は一部の偶発パターンに対する証拠であり、能動攻撃者に対する証拠ではない。

RFC 3309 と後の RFC 4960、RFC 9260 は SCTP にも CRC32C を用いた。この再利用は研究された符号の価値を示すが、誤りモデルの同一性は示さない。パケット長、対象フィールド、下位層、回復規則、失敗の結果が違えば、同じ多項式の証拠価値も文脈化が必要である。

古い Internet チェックサム文書も、名称が単一保証ではないことを示す。RFC 1071 は効率的計算、RFC 1141 と RFC 1624 は増分更新を扱い、後者は前者の式の問題を修正した。RFC 2151 は UDP 用 Fletcher、RFC 1950 は zlib の Adler-32 を記述した。目的と境界を無視して幅だけで交換はできない。

文書末尾のシステム警告も重要である。固定時間のバーストは通信速度が上がるほど多くのビットを覆う。上位 CRC は対象単位の検出を改善できても、長期リスクを単独で一定に保てない。下位層の符号化改善と誤り率低下も同じ制御面に残る。

Lu Heng の最小初期仕様という視点では、生成多項式、ビット配置、交渉範囲が共有決定である。実装はハードウェアやソフトウェアの最適化を自由に選べるが、通過という事実の意味までローカルに変えてはならない。

現実層の視点では、欄が存在する、アルゴリズムを実装する、セッションで合意する、PDU が対象になる、検証に通る、特定モデルの偶発破損を排除する、対抗的完全性を確立する、は七つの事実である。「32ビット・チェックサムあり」は七層を一つの記号へ圧縮し、ほとんど何も証明しない。

RFC 3385 の歴史的貢献は CRC32C の推薦だけではない。完全性の標語を、境界付きの証拠へ変える方法を示した。ビット数は外殻であり、その意味を決めるのは多項式、ブロック、負荷、経路、脅威モデルだった。

出典