AEAD（関連データ付き認証付き暗号）.

関連データ付き認証付き暗号（AEAD）は、現代の対称暗号における基本的な構成要素である。AEAD スキームは、鍵、ノンス、平文、および任意の関連データ（AD）を受け取り、暗号文と認証タグを生成する。復号時には、タグが検証された場合にのみ平文を返し、そうでなければ拒否する。関連データは認証されるが暗号化はされない。これにより、プロトコルはパケットヘッダー、シーケンス番号、バージョンメタデータといった暗号化されていないコンテキストを、暗号化して送信することなく暗号文に束縛できる。

encrypt-then-MAC や MAC-then-encrypt の組み合わせと比較して、AEAD はバグのクラス全体を排除し、TLS 1.3、QUIC、IPsec ESP-GCM、Signal、Noise、WireGuard、JWE といったあらゆる現代のプロトコルが採用しているものである。歴史がその重要性を示している。Lucky 13（2013 年）と POODLE（CVE-2014-3566）の攻撃はいずれも、TLS における脆弱な MAC-then-encrypt の CBC 構成を悪用したものであり、AEAD によるレコード保護への移行がそれらの扉を閉ざした。この形式モデルは 2002 年に Rogaway によって定義され、RFC 5116 として標準化され、具体的なスキームは IANA によって登録されている。

支配的な AEAD スキームは AES-GCM（AES-NI および PCLMULQDQ によりハードウェアアクセラレーションされる）と ChaCha20-Poly1305（RFC 8439、モバイル CPU 上のソフトウェアで高速）である。どちらも（鍵, ノンス）のペアが繰り返されると壊滅的に失敗する。GCM におけるノンスの再利用は認証鍵を漏洩させる可能性がある。一意なノンスが保証できない場合、ノンス誤用耐性を持つ AES-GCM-SIV（RFC 8452）は、漏洩を 2 つの平文が等しかったかどうかに限定する。自作の encrypt-and-MAC の組み合わせよりも、常に検証済みの AEAD を優先すべきである。

flowchart LR
  K[鍵] --> ENC
  N[ノンス] --> ENC
  P[平文] --> ENC[AEAD 暗号化]
  AD[関連データ<br/>ヘッダー · ID] --> ENC
  ENC --> CT[暗号文]
  ENC --> TAG[認証タグ]
  CT --> DEC[AEAD 復号]
  TAG --> DEC
  AD --> DEC
  K --> DEC
  N --> DEC
  DEC --> V{タグは有効か？}
  V -->|はい| OUT[平文を返す]
  V -->|いいえ| REJ[拒否 · 平文は漏洩しない]