OpenVPN ECとED：なぜこの名前は強度の梯子ではないのか

ec、ed、ecdh、ecdsa、auth とTLS暗号リストを一つのプロファイルに並べると、そのファイルは六段階の強度ダイヤルのように見え始めます。しかし実際はそうではありません。各名前は別々の問いに答えており、そのどれか一つが異なる二つのプロファイルが、必ずしも互いに強いとか弱いとかいうことにはなりません。名前をその役割ごとに並べ替えるのに五分ほどかけるだけで、動作している設定に対して人が加える悪い編集のほとんどを防げます。

以下の整理は混乱そのものから始まり、そこから外側へ、あなたのトラフィックを実際に守っているものを決めるプロファイルの部分へと進みます。各節は誤読を一つずつ取り上げ、その名前が本当は何に結びついているのかを示します。

二文字、二つの別の問い

最も議論を呼ぶのはECとEDの組み合わせで、その議論はたいてい、両者が一つの問いに対する競合する答えだと思い込んでいます。両者は同じ軸にすらありません。ECは数学の一族を表し、その名は楕円曲線暗号で、安全性は大きな有限体の中ではなく曲線上の離散対数の難しさから来ます。

EDはその一族の中の曲線の形を表します。Twisted Edwards曲線は、速度と複数の実装上の誤りへの耐性のために選ばれた表現で、Ed25519は人が普通に指す名前です。この曲線は楕円曲線暗号の競合相手ではなく、楕円曲線を書く方法の一つです。EDを「より新しく強いEC」と読むのが最初の誤った曲がり角であり、その後のすべては同じ方向に誤りがちです。

署名と鍵交換は別の仕事

一族についての問いが片づくと、残りの名前は互いに決して代用できない二つの列に分かれます。一方の列は署名し、もう一方は共有秘密に合意します。

EdDSAとECDSAはどちらも署名しますが、鍵の形式が異なる別の方式なので、一方のために発行された証明書は他方としては使えません。EdDSAは少数の曲線の集合に対して定義されており、P-256はそのどれでもないため、P-256の証明書はECDSAで検証され、Ed25519で検証されることはありません。

鍵交換の列にはEdDHという名の対応物はありません。Curve25519の鍵に対する一時的な合意はX25519で、これは特定の曲線を使ったECDHであり、P-256の場合とまったく同じです。Ed25519は厳密には署名方式を指しますが、二つの曲線が関係しているためこの名前は鍵交換にも緩く使われ、署名に使うEdwards形式とX25519に使うMontgomery形式は同じ基礎群を表します。

ECプロファイルにdhファイルがない理由

dhファイルには有限体Diffie-Hellman用の事前生成パラメータが入っており、そうしたパラメータが存在するのは、大きな素数と生成元をどこかから持ってくる必要があるからです。楕円曲線の鍵交換には不要で、名前付き曲線がパラメータの集合そのものであり、双方がすでにそれを知っています。これがECプロファイルがその指示子を省略できる理由のすべてです。

それ以外は現代的に見えるプロファイルにも、dh行が生まれる状況が二つあります。一つ目は、有限体の群を本当に交渉する二つ目のリスナーや古いピアです。二つ目は、RSA時代のテンプレートからコピーされて削除されなかった残骸のテキストです。鍵交換に曲線を指定しながら2048ビットのdhファイルを読み込んでいるプロファイルは、そのせいでより安全になるわけではなく、使われない遺物を抱えているだけです。

TLS 1.3は名前から鍵交換を外した

TLS_AES_256_GCM_SHA384とTLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384を比べると、短い名前は格下げに見えます。これは改名であり、理由は構造的です。TLS 1.3は静的RSAと有限体Diffie-Hellman鍵交換を削除したため、一時的な楕円曲線鍵交換がPSK以外で唯一残る選択肢になりましたが、すべてのスイートでそれを名指しすれば同じ事実を十二回繰り返すことになります。

証明書の種類が名前から消えたのも関連する理由からです。1.3では証明書はハンドシェイクの署名を認証するもので、鍵合意を認証するのではないため、スイートを選ばなくなりました。設定に1.3専用の暗号リストがあるのも同じ理由で、スイートは改名され再編されたのであって、弱くなったのではありません。

一つの帰結は率直に言う価値があります。ECDHEは鍵交換アルゴリズムであり、決して暗号ではありません。「楕円」と説明されるスイートは、二つのピアが共有鍵にどう至ったかについて何かを語り、その後にペイロードを何が暗号化するかについては何も語りません。

authはパケットを認証し、ペイロードは認証しない

auth指示子はパケットを認証するHMACダイジェストを選び、その歴史的な既定値はSHA1です。AEADでないデータ暗号では、OpenVPNは暗号文に対してダイジェストを計算して付加する暗号化してからMACという配置をとり、それがパディングの改ざんを非現実的にしています。

ここでの神話は、authをSHA512に上げるとトンネルが堅牢になるというものです。暗号の強度は上がりませんし、交渉されたデータ暗号がAES-256-GCMのようなAEADモードであれば、ダイジェストはデータパケットにはまったく適用されません。GCMタグがすでにそれらを認証しており、authの値は制御チャネルのHMACと、まだ使われているAEAD以外の暗号のために残されます。

つまりこの指示子は重要ですが、ファイル内での位置が示すよりも狭い場所で重要です。実際にどの暗号が交渉されたかを確認すれば、そもそも適用されるのかどうかがわかります。

プロファイルは順位ではなく列で読む

三つの問いが層をきれいに分け、それぞれに交渉されたセッションの別の部分が答えます。どの暗号がペイロードを守るのか。どのタグやダイジェストが各パケットを保証するのか、そして使われている暗号はそもそもそれを必要とするのか。誰の証明書がハンドシェイクを閉じたのか、そして制御チャネルはさらにtls-authやtls-cryptで守られているのか。

ECやEDというラベルのどこにも、その三つのどれかを決めるものはなく、スイート名だけでも同じくどれも決まりません。交渉された結果だけが証拠なので、語彙から強度を推測するのではなくそれを読んでください：

openssl x509 -in client.crt -noout -text | grep -E 'Signature Algorithm|Public Key Algorithm'
grep -i 'control channel' /var/log/openvpn.log

一つ目のコマンドは、あなたの証明書が実際にどの署名方式を使っているかを教えてくれ、それがECDSAで動いているのかEd25519で動いているのかを知る唯一の確実な方法です。二つ目は、クライアントがそのセッションのために記録した制御チャネルの行を、TLSバージョンと落ち着いたスイートを含めて表示します。プロファイルの変更がこれら二つの出力のどちらでも正当化できないなら、それはおそらく性質ではなく名前の変更です。