AEAD が加えるのは完全性であり、ログインでも実用的な経路でもない

認証付き暗号は、一度に二つのものを返す。内容を隠す暗号文と、受信者が改ざんを検出できるタグである。以前はこれらの機能を別々の部品から組み立てており、まずい組み合わせが微妙な不具合を生んだ。現代の構成は組み合わせ方と、それが成り立つ条件を定めている。ここでの認証とはタグのことを指し、人を指すのではない。

どちらの保証も保護されたパケットにのみ及び、その外側には及ばない。

一つの構成に二つの保証

暗号化は、観察者がこれを読めるかという問いに答える。完全性は、改変されたかという問いに答える。トンネルには両方が必要だ。改変された内容は、読めない内容より悪いからである。AEAD は、認証されるが暗号化されない関連データとともに、両者を一つの鍵の下でどう組み合わせるかを定める。受信者は検査に失敗した入力を受け入れずに拒否する。

関連データは、見えるフィールドを検査に結び付ける。どのフィールドがそうなるかはプロトコル次第であり、外側のアドレスがすべて秘密になったという約束ではない。フィールドはタグで覆われたまま、ネットワーク上で読めることもある。

ノンスは些細な話ではない

鍵とノンスは正しく扱う必要があり、ノンスの再利用は穏やかには失敗しない。同じ鍵の下でノンスを繰り返すと、メッセージ間の関係が露わになり、完全性の保証が根底から崩れる。だからノンスの生成と順序は、アプリケーションではなくプロトコルが担う。

これは保証の条件であり、実装上の助言ではない。不注意なノンスでは、宣伝された性質は得られない。

再生保護は別の状態

タグが無傷のままでも、正しい古いパケットは再生できる。タグが証明するのは真正性であり、鮮度ではないからだ。再生の処理には独自の状態が要る。シーケンス番号、ウィンドウ、何を受け入れるかの規則である。その状態はプロトコルの実装にあり、暗号の選択とは関係がない。強い暗号化があっても再生保護のないトンネルは、昨日の通信を今も受け入れる。

二つの仕組みは同一ではなく協働し、一方が正しくても他方が欠けることがある。

タグが教えないこと

相手の身元は証明書や事前共有鍵で確立され、暗号が認証付きであることでは決まらない。経路、名前解決、運営者のログ方針は暗号の境界の外にある。アルゴリズムの交渉が成功したというのは、両端が一つのスイートで合意したというだけで、互換性の話であり、どちらの側の実装の質の話ではない。

利用者にとっての実務的な指示は、保守され支援されているプロトコル構成を選ぶことだ。AEAD はその構成の性質であり、トンネルの周りに暗号を手作業で組む招待ではない。

どのスイートが交渉され、再生保護が有効か、相手をどう識別するかを記録する。三つの事実、三つの異なる保証である。