AES-256 と OFB：VPN 暗号の構成全体を選ぶ

AES-256 と OFB は別の問いに答えており、両者を競合する選択肢として扱うところに暗号レビューの誤りがあります。一方は鍵長を伴うブロック暗号を名指しし、他方はブロック暗号がより長いメッセージのためにストリームへ変換される仕組みを説明します。保護を選ぶ手順書は、受信側が改変されたパケットをどう検出するかを含め、構成全体を見なければなりません。

構成の四つの部分を名指しする

どのレビューも四つの問いに還元されます。どの基本暗号と鍵長か、それでメッセージをどう処理するか、受信側が不正な改変をどう拒否するか、プロトコルが入力と鍵とその寿命をどう管理するか。よく知られた名前の一覧が答えるのは一つ目だけです。二つ目と三つ目に本当の違いがあり、四つ目で実装が静かに分かれます。その順に問い、答えを書き留めてください。

OFB は NIST のブロック暗号モードの刊行物で機密性モードの一つとして挙げられており、機密性だけを提供します。暗号化モードを別個の MAC と組み合わせるプロトコルは、両者を正しく合成しなければならず、アルゴリズム名はその合成を証明しません。だからモード名だけでは導入の判断を決められません。

四つ目の問いは、運用者が稼働中のシステムで実際に確認できるものです。

認証付きの構成を優先する

認証付き暗号化は機密性と完全性を同時に与え、AEAD 構成は関連データも暗号化せずに改変から守ります。これはパケット保護の性質であり、人が正常にサインインしたかどうかとは関係ありません。

Netgate の Netgate による OpenVPN 暗号設定のガイダンス はデータチャネル向けに AEAD の選択肢、その中でも AES-GCM を指しており、これが従うべきサポートされたポリシーの種類です。導入済みのリリースとピアのクライアントが対応する選択肢を使い、過去のモード順位を新しい配備にコピーしないでください。旧来の互換性、暗号バックエンド、オフロード対応が実際に利用できるものを制限します。

サポートされた構成は、巧妙な合成に毎回勝ります。

提案ではなく合意された結果を読む

受け入れリストに暗号があることは、現在のセッションについて何も語りません。クライアントまたはゲートウェイから合意されたデータチャネル保護を読み、適用しようとしたポリシーと比較してください。古いピアのために旧来の選択肢を依然として列挙している設定は互換性の判断であり、目の前のセッションについての表明ではありません。

openvpn --config client.conf --verb 4 2>&1 | grep -Ei 'cipher|data channel|auth'

ゲートウェイでは同等の出力は、プラットフォームに応じてセキュリティアソシエーションか接続の暗号詳細です。どちらの場合も提案と結果は別の事実です。古いピアのために旧来の選択肢を含む一覧は、すべてのセッションがそれを使うという意味ではなく、使っているセッションこそ知る必要があったことです。

両方の事実を、日付とクライアントのバージョンとともに記録してください。

比較できるものだけを測る

スループットは端点のハードウェア、実装、アクセラレーション、パケットサイズ、選択した設定に依存します。鍵の長さも OFB という語も、どちらの配備が速いかは教えてくれません。だから他所のベンチマークは、せいぜい他人が持つハードウェアについての手がかりです。自分の数値は自分の端点から始まります。

許可された比較では、端点、作業負荷、要求されるポリシーを一定に保ち、合意された保護と実装のバージョンを記録します。そのうえで、アプリケーションが完了したか、どれだけ失ったか、端点が何をしていたかで結果を判断し、単一の速度テストから暗号コストを推測しないでください。別の条件で出た数値は物語であり、測定ではありません。

古いピアがポリシーを満たせないなら、それはその所有者にとっての互換性の判断です。

完全性を取引から外す

完全性の検査を切ることも、検証されていないサーバーを受け入れることも、性能最適化ではなく互換性の修正でもありません。構成が提供するために選ばれたセキュリティ特性を変えてしまいます。受け入れ暗号の一覧を古いピアが接続するまで広げるのも同じで、接続は成功し、ポリシーはもう存在しません。

受け入れた構成とその所有者を手順書に書き、次の変更が好みではなく判断から始まるようにしてください。

望むのは双方が適用できるポリシーです。どちらの名前が最強かという議論は別の話であり、たいてい判断なしに終わります。