EAX 是否使用相同的密鑰進行加密和身份驗證？
我實際上正在檢查 EAX AEAD 模式的使用，並遵循 EAX 規範審查（我的方案定義），我的問題是：身份驗證和加密密鑰的派生怎麼樣？在所描述的方案中，相同的輸入鍵 $ K $ 出現在所有 OMAC（身份驗證）和 CTR 功能上。我是否錯過了一些重要的事情，因為 EAX 不遵守不同身份驗證/加密密鑰的要求會令人驚訝？
我還有另外兩個問題，但不太重要：
- 在與 GCM 進行比較時，我注意到在 MAC 計算中沒有考慮 C/AD 長度參數。它對安全性（消息擴展攻擊）有真正的重要性嗎？
- CTR 功能的初始計數器 ICB 來自一次 OMAC 操作；因此，由於 ICB LSBits 未設置為 0 值，這意味著在 CTR 函式的每個分組密碼呼叫中處理 128 位字的增量？
在 EAX 中確實使用相同的密鑰來加密 CTR 模式和底層 OMAC（實際上在 3 個不同的階段中使用：隨機化 CTR 隨機數、驗證附加驗證數據和驗證密文）。這在安全證明中得到明確承認。
EAX 與簡單重用密鑰的不同之處在於，它使用不同的參數初始化 OMAC 的每次使用，並使用 OMAC 輸出之一初始化 CTR 模式密碼，從而有效地將其隨機化。這種單一密鑰方法的安全證明是（引用作者的話）“新穎且涉及”和“令人驚訝的複雜”，但似乎經得起同行評審。
值得注意的是，在 EAX 論文中，實際上定義了 3 種模式：
- EAX2 是一種通用組合方法，用於組合密碼和 MAC 以使用兩個密鑰 Key1 != Key2 生成經過身份驗證的密碼。
- EAX1 是 EAX2 與一個 Key == Key1 == Key2 的組合
- EAX 是 EAX1 與 CTR 和 OMAC 的組合
EAX 論文中的安全證明是為 EAX2 和 EAX 提供的，而不是 EAX1（EAX 的證明依賴於 OMAC 的屬性，因此沒有擴展到 EAX1 的一般用途）。
Ciphertext 和 AAD 的長度在 EAX 中沒有明確處理，這允許 EAX 作為線上模式執行（在數據到達時處理數據而不緩沖一個以上的塊）。EAX 中的身份驗證只是使用 OMAC 處理 AAD 和 Ciphertext 的整個序列，並且該安全證明（以及任何其他安全 MAC）自然排除任何消息擴展攻擊 - 任何導致相同 MAC 的消息擴展都是偽造的，並立即使該方案作為安全 MAC 無效。
CTR 模式必須在任何實現中處理隨機數/計數器值的增量 - 計數器的起始值是任意的（在 EAX 偽隨機的情況下）。這並不難（例如，BouncyCastle 在一行程式碼中就做到了）。