XAES-256-GCM 拡張ノンス AEAD

 (words.filippo.io)
1 ポイント 投稿者 GN⁺ 2024-06-30 | 1件のコメント | WhatsAppで共有

XAES-256-GCM の紹介

  • XAES-256-GCM は、256ビット鍵と192ビットノンスを使用する認証付き暗号アルゴリズム（AEAD）
  • 主な目標:
    • ランダムに生成されたノンスを安全にサポート
    • FIPS 140 準拠
    • 一般的な暗号化ライブラリで容易に実装可能

XAES-256-GCM の設計目標

  • 大きなノンスを使用することで、無制限のメッセージに対して安全にランダム生成が可能
  • FIPS 140 準拠により、さまざまな環境で利用可能
  • シンプルな実装によってユーザーの負担を軽減

XAES-256-GCM の動作原理

  • AES-256-GCM をベースにした拡張ノンス構造を使用
  • 入力鍵とノンスを使って派生鍵を計算
  • 3回の AES-256 呼び出しでメッセージを処理

実装と最適化

  • Go のリファレンス実装は 100 行未満のコードで構成
  • 標準ライブラリの crypto/cipher と crypto/aes のみを使用
  • NIST SP 800-108r1 KDF と NIST AES-256-GCM AEAD を用いて説明可能

サードパーティ実装と互換性

  • .NET 8+、pyca/cryptography、Web Cryptography API にサードパーティ実装が存在
  • FIPS 140 準拠のためラウンド数は変更不可

代替案とテストベクター

  • AES-GCM-SIV など、さまざまな代替案が存在
  • 主要なコードパスに対するテストベクターを含む

要約

  • XAES-256-GCM は、安全で準拠性があり、相互運用可能な AEAD として設計されている
  • XChaCha20Poly1305 および AES-GCM-SIV を補完する役割
  • Go 標準ライブラリへの追加が期待される

GN⁺ の見解

  • XAES-256-GCM は、大きなノンスを使って安全性を高めている点が注目に値する
  • FIPS 140 準拠により、さまざまな環境で利用可能
  • Go のような言語で容易に実装でき、開発者にとって有用
  • AES-GCM-SIV のような代替案も検討に値する
  • 新しい技術を導入する際は、性能と互換性を慎重に検討する必要がある

関連記事

1件のコメント

 
GN⁺ 2024-06-30
Hacker Newsのコメント

  • 設計が非常に巧妙: CMACベースで、低レベルのプリミティブがない場合でも AES-CBC を使って鍵を導出できる

    • AES-CBC の用語で説明すると: 
      1. L = AES-CBC-256ₖ(iv = 0¹²⁸, plaintext = 0¹²⁸)[:16]
2. MSB₁(L) = 0이면, K1 = L << 1;
   그렇지 않으면 K1 = (L << 1) ⊕ 0¹²⁰10000111
3. M1 = 0x00 || 0x01 || X || 0x00 || N[:12]
4. M2 = 0x00 || 0x02 || X || 0x00 || N[:12]
5. Kₓ = AES-CBC-256ₖ(iv = K1, plaintext = M1)[:16] || AES-CBC-256ₖ(iv = K1, plaintext = M2)[:16]
6. Nₓ = N[12:]
    • AES-CBC-256 は最初の 128 ビットブロックを返し、パディングされたブロックは破棄される
    • 鍵を導出した後は標準の AES-GCM とともに使用
    • WebCrypto API ベースの JS 実装例: GitHubリンク
    • AES-CBC 用に意図された適切な CryptoKey を受け入れ、IndexedDB に保存可能

  • Filippo の仕事は素晴らしい: ランダム nonce を使う場合、約 2^32 メッセージごとに鍵をローテーションしなければならない問題を解決している

    • AES-GCM では nonce の衝突は致命的 (攻撃者が任意のメッセージに署名できるようになる)
    • ランダム nonce を使う必要はないが、一般的には推奨される
    • 2つのプリミティブ (カウンタベース KDF と通常の GCM) を使って FIPS 準拠にしたのは非常に巧妙

  • この機能が数年前に暗号化ファイルシステムを書いたときに存在していてほしかった

    • nonce の衝突は大規模なファイルシステム展開で大きな問題になる
    • 2^32 は大きく見えるが、秒間 100k IOPS を書き込む PB アレイでは、PRNG のランダム性に依存すると衝突の可能性はほぼ保証される

  • この機能が、アーカイブファイル暗号化向けの FIPS 準拠版 age[1] に使われてほしい

    • 銀行業界の監査担当者は、ChaCha ではなく AES を使っていないという理由で age に反対していた (X25519 の公開鍵部分は最近 NIST に承認された)
    • golang の経験はないが、age の仕様に従えば簡単に適用できそう
    • 時間が許せば試してみるつもり
    • 「cage」と呼ぶつもり ("compliant actually good encryption" の略)

  • 非暗号学者からの質問: なぜ 192 ビット nonce を使い、256 ビットを使わないのか気になる

    • 実用的なアプリケーションでは、追加のビットのコストはそれほど高くないように思える

  • (2⁸⁰ メッセージで衝突リスク 2⁻³²)

    • AES のブロックサイズが 128 ビットなので、その前に問題が発生し得るのではないかと気になる