CFB1・CFB8・CFB128 はフィードバック長であり、鍵長ではない

AES-256-CFB1 のような名前には二つの数字が含まれ、それぞれ別の問いに答えています。256 は AES の鍵長です。1 は CFB のフィードバック、つまりセグメント長であり、モードが状態をどう進めるかの性質です。1 を鍵長として読むと、その名前は致命的な設定ミスに見えます。だからこの疑問は繰り返し戻ってくるのです。

名前を判断する前に、三つの量のどれを見ているのかを決めてください。鍵長、ブロック長、セグメント長です。通常の意味でセキュリティパラメータなのは最初の一つだけです。

三つの数字、三つの量

AES は 128、192、256 ビットの鍵を受け付け、どれを選んでもブロックは 128 ビットです。ブロック長は AES に属し、モードに属しません。CFB の接尾辞は三つ目の量で、モードがステップごとに消費し返すデータ量を表します。OpenSSL の AES ドキュメントは、CFB 系の各変種についてこのシフト幅を明示しています。

CFB1 はビット単位で、CFB8 はバイト単位で、CFB128 はブロック全体を返します。三つとも内部では同じ 128 ビットのブロック暗号を使い、変わるのは計算した各ブロックのうち何ビットを処理ごとに使うかです。だから接尾辞が動かすのは鍵の強さではなく、コストとバッファの挙動です。

ブロック長が決して変わらない理由

AES はブロック長 128 ビット固定のブロック暗号で、モードはその周りの構成です。どれもセグメント長に合わせてブロックを縮めません。CFB1 の実装も常に AES ブロック全体を計算し、結果からビットを一つだけ取ります。残りのビットはそのステップで捨てられ、まさにそこに効率のコストがあります。

つまりビット単位のフィードバックはビット単位の鍵を意味せず、名前を接尾辞で順位付けすることもできません。CFB128 は CFB32 の四倍の強さではなく、より大きなセグメントを処理します。

セグメント長が実際に変えるもの

セグメント長が変えるのは、ステップごとに返す暗号文の量と、各ステップが運べる平文の量です。誤りの伝播やバッファの挙動も変わり、これはストリーム的な用途で重要です。バイト単位のセグメントはバッファと整合し、ビット単位のものは整合しません。

実際にはモードを選ぶのはプロトコルであり、運用者ではありません。VPN のデータチャネルは、そのプロトコルが定める構成を独自の完全性保護とともに使います。ライブラリの一覧は、どんな名前が存在するかを示すだけです。

修飾のない CFB ラベルを読む

修飾のない CFB というラベルには、実装の文脈が必要です。OpenSSL 1.0.2 のヘッダーでは、EVP_aes_128_cfb は EVP_aes_128_cfb128 のマクロで、192 ビットと 256 ビットの鍵にも対応する別名があります。これは一つの系列における API の命名慣行であり、あらゆるライブラリやファイル形式、GUI が同じように略語を展開するという主張ではありません。目の前のバージョンのヘッダーやドキュメントを確認してください。

旧来のプロファイルが CFB と言い、相手がそれを受け入れるなら、ネゴシエートされたパラメータはどこかに記録されています。ログ、設定のダンプ、API の応答です。表示文字列からセグメント長を推測するのではなく、それらを読んでください。

モード名が教えてくれないこと

名前が説明するのは暗号化の挙動だけで、それ以外ではありません。VPN には完全性保護、鍵導出、相手の認証が依然として必要で、CFB はそのどれも提供しません。CFB8 を CFB1 に替えるのも見た目の話ではありません。ネットワーク上の挙動が変わり、両端が同じ構成を支える必要があります。ライブラリに名前があるからといって、配備されたゲートウェイが自分のデータチャネルでそれを受け入れる証拠にはなりません。

保守されるものについては、プロトコルの完全な保護構成と運用者の方針を用い、ライブラリとゲートウェイのバージョン、正確なオプション、ネゴシエート結果を記録してください。古い名前は、いま読んでいるものを説明しますが、その設定を復活させる根拠にはなりません。