為整個消息選擇經過身份驗證的加密模式
有幾種廣受好評的用於認證加密的分組密碼模式已進入標準和協議：CCM、EAX、GCM、OCB ……
如果我正在設計一個新的消息傳遞或儲存協議，它需要數據的機密性和真實性，我該如何在這些模式之間進行選擇？我對全消息加密和完整性驗證（而不是塊儲存）特別感興趣。
我在尋找諸如“選擇在您的程式環境中容易獲得的 X 或 Y 中的任何一個”或“此模式的填充很難實現，但它對損壞的 RNG 更健壯”之類的答案。
（這符合AES CBC 模式或推薦的 AES CTR 模式的精神？僅用於提供機密性的模式。）
GCM
就個人而言，我會選擇 GCM（伽羅瓦計數器模式），因為它很高效——這意味著：它幾乎可以處理您期望從中得到的所有東西，而其他模式有時往往會在這里和那裡缺乏特定的功能（見下圖比較顯示我在暗示什麼）。此外，GCM 具有相當不錯的性能（假設實現無缺陷）。正如您很可能已經知道的那樣，它提供了具有眾所周知的 CTR 模式加密的 Galois 身份驗證模式。CTR 方面實際上意味著它不需要任何填充（這避免了相關的攻擊可能性），這意味著您在消息/包長度方面保持一定的靈活性（例如 CCM 不提供的東西，因為它使用固定的塊長度）。此外，用於認證的伽羅瓦域乘法可以並行計算，與那些使用連結模式（如 CBC 等）的身份驗證算法相比，它可以實現更高的速度/吞吐量。順便說一句：如果您決定檢查 GCM，您可能會發現知道這一點很方便NIST 特別出版物 800-38D包括有關 IV 選擇等的建議。
其餘的部分…
我列表頂部的替代方案是 EAX 模式，它還提供了幾個理想的屬性。但是：EAX 是一種“兩遍方案”……使其比基於相同原語的精心設計的單遍方案要慢。由於您設計了消息傳遞/儲存協議，因此您可能希望掌握所有可以得到的速度。在這種情況下，兩次通過似乎不是一種選擇，將 EAX 推到了列表的下方。
現在，您還提到了 CCM。該模式僅針對塊長度為 128 位的塊密碼定義，這對於消息傳遞等可能有點限制。這就是為什麼我想再次提醒你 GCM 的計數器模式……
你提到的最後一個是OCB。想到 OCB 我有點不舒服，因為弗格森在 OCB 上發現了碰撞攻擊。該攻擊將可以使用 OCB 安全加密的數據限制在每個密鑰大約 64GB 左右。這與 GCM 的 64 GB 限制大致相同（GCM 將明文大小限制為 $ 2^{39} − 256 $ 任何給定密鑰和 IV 組合的位），但我們必須記住 GCM 的限制是*“設計使然”* ……在 OCB 的情況下，它是*“碰撞攻擊的結果”*。因此，從安全形度來看，我傾向於避免 OCB。我們都知道攻擊只會變得更好。
還有一些其他的東西可能有意義也可能沒有意義，這取決於個人設置……但最後，我個人建議將 GCM 用於消息傳遞和儲存協議。
比較一些選項……
為了進行比較，您可能還想查看David Wagner的這個 PPT 文件的幻燈片 7 上的漂亮比較表。為了閱讀方便，我將在此處引用它作為圖形（您會注意到GCM 是贏家）：
編輯
有時，在記住我曾經讀過的論文時，我的大腦似乎有點慢。
無論如何，我很有信心您會喜歡閱讀“身份驗證加密模式的基本比較（IAPM、XCBC、OCB、CCM、EAX、CWC、GCM、PCFB、CS）”（PDF），它比較了一大堆模式在屬性、速度、實現、記憶體使用情況、顯示每種模式的底層塊密碼呼叫數量等的表格方面。
讀完之後，你手頭會有足夠的資訊來決定什麼是最有意義的。
