在哪些情况下首选它们中的哪一个？
我想查看各种模式的评估标准列表，并可能讨论每个标准的适用性。
例如，我认为标准之一是加密和解密的“代码大小”，这对于微代码嵌入式系统很重要，例如 802.11 网络适配器。如果实现 CBC 所需的代码比 CTR 所需的代码小得多（我不知道这是不是真的，这只是一个例子），那么我可以理解为什么使用更小的代码的模式会更受欢迎。但是，如果我正在编写一个在服务器上运行的应用程序，并且我使用的 AES 库无论如何都实现了 CBC 和 CTR，那么这个标准就无关紧要了。
看看我所说的“评估标准列表和每个标准的适用性”是什么意思？？
这与编程无关，但与算法有关。
事情的丑陋事实是，如果您提出这个问题，您可能无法设计和实施安全系统。
让我来说明一下我的观点：假设您正在构建一个 Web 应用程序，并且需要存储一些会话数据。您可以为每个用户分配一个会话 ID，并将会话数据存储在服务器上的哈希映射中，将会话 ID 映射到会话数据。但是你必须在服务器上处理这种讨厌的状态，如果在某些时候你需要多个服务器，事情就会变得一团糟。因此，您有想法将会话数据存储在客户端的 cookie 中。您当然会对其进行加密，因此用户无法读取和操作数据。那么你应该使用什么模式呢？来到这里，您阅读了最佳答案（很抱歉将您从 myforwik 中挑出来）。第一个 - ECB - 不适合你，你想加密多个块，下一个 - CBC - 听起来不错，你不需要 CTR 的并行性，你不需要随机访问，所以没有 XTS 和专利是 PITA，所以没有 OCB。使用您的加密库，您意识到您需要一些填充，因为您只能加密块大小的倍数。你选PKCS7，因为它是在一些严肃的密码学标准中定义的。在某处读到 CBC与随机 IV 和安全分组密码一起使用时可证明是安全的之后，即使您将敏感数据存储在客户端，您也可以放心。
多年后，在您的服务确实发展到相当大的规模后，IT 安全专家会在负责任的披露中与您联系。她告诉您，她可以使用padding oracle attack解密您的所有 cookie ，因为如果 padding 以某种方式损坏，您的代码会生成错误页面。
这不是一个假设的场景： 直到几年前，微软在 ASP.NET 中存在这个确切的缺陷。
问题是密码学存在很多陷阱，构建一个对于外行来说看起来很安全但对于知识渊博的攻击者来说很容易破解的系统非常容易。
对于实时连接，请使用 TLS（请务必检查证书的主机名和颁发者链）。如果您不能使用 TLS，请查找您的系统必须为您的任务提供的最高级别的 API，并确保您了解它提供的保证，更重要的是它不保证什么。对于上面的例子，像Play这样的框架提供了客户端存储设施，但它不会在一段时间后使存储的数据失效，如果你改变了客户端状态，攻击者可以在你不注意的情况下恢复以前的状态。
如果没有可用的高级抽象，请使用高级加密库。一个突出的例子是NaCl，具有多种语言绑定的可移植实现是Sodium。使用这样的库，您不必关心加密模式等，但您必须更加小心使用细节，而不是使用更高级别的抽象，例如从不使用 nonce 两次。对于自定义协议构建（比如你想要 TLS 之类的东西，但不是通过 TCP 或 UDP），有像Noise和相关实现这样的框架可以为你完成大部分繁重的工作，但它们的灵活性也意味着有很大的出错空间，如果您不深入了解所有组件的作用。
如果由于某种原因您不能使用高级加密库，例如因为您需要以特定方式与现有系统进行交互，那么就没有办法彻底教育自己。我推荐阅读Ferguson、Kohno 和 Schneier 的 Cryptography Engineering。请不要自欺欺人地相信您可以在没有必要背景的情况下构建安全系统。密码学非常微妙，几乎不可能测试系统的安全性。
为了防止填充预言攻击和对密文的更改，可以在密文上计算一个消息认证码（MAC），并且只有在它没有被篡改的情况下才解密它。这称为 encrypt-then-mac 并且应该优先于任何其他命令。除了极少数用例，真实性与机密性一样重要（后者是加密的目的）。认证加密方案（带有关联数据 (AEAD)）将加密和认证两部分过程组合成一个分组密码模式，该模式也会在该过程中产生一个认证标签。在大多数情况下，这会提高速度。
考虑到身份验证的重要性，对于大多数用例（磁盘加密目的除外），我建议使用以下两种分组密码模式：如果数据通过非对称签名进行身份验证，则使用 CBC，否则使用 GCM。
如果使用相同的密钥加密多个数据块，则不应使用 ECB。
CBC、OFB和CFB类似，但是OFB/CFB更好，因为你只需要加密而不需要解密，这样可以节省代码空间。
如果您想要良好的并行化（即速度），则使用 CTR，而不是 CBC/OFB/CFB。
如果您正在编码随机可访问的数据（如硬盘或 RAM），则 XTS 模式是最常见的。
OCB 是迄今为止最好的模式，因为它允许一次性加密和身份验证。但是在美国有专利。
你真正需要知道的唯一一件事是，除非你只加密 1 个块，否则不要使用 ECB。如果您要加密随机访问的数据而不是流，则应使用 XTS。
Phil Rogaway 于 2011 年在此处进行了正式分析。第 1.6 节给出了我在此处转录的摘要，并用粗体添加了我自己的重点（如果您不耐烦，那么他的建议是使用 CTR 模式，但我建议您阅读下面我关于消息完整性与加密的段落）。
请注意，其中大多数要求 IV 是随机的，这意味着不可预测，因此应该使用密码安全性生成。但是，有些只需要一个“nonce”，它不要求该属性，而只要求它不被重复使用。因此，依赖随机数的设计比不依赖随机数的设计更不容易出错（相信我，我见过很多没有通过适当的 IV 选择来实现 CBC 的情况）。因此，您会看到，当 Rogaway 说“当 IV 是随机数时无法实现机密性”时，我添加了粗体字，这意味着如果您选择 IV 加密安全（不可预测），那么没问题。但是，如果您不这样做，那么您将失去良好的安全属性。 切勿将 IV 重复用于任何这些模式。
此外，了解消息完整性和加密之间的区别也很重要。加密隐藏数据，但攻击者可能能够修改加密数据，如果您不检查消息完整性，您的软件可能会接受结果。虽然开发者会说“但是修改后的数据在解密后会变成垃圾”，但一个好的安全工程师会发现垃圾在软件中引起不良行为的概率，然后他会将这种分析变成真正的攻击。我见过很多使用加密的情况，但确实比加密更需要消息完整性。了解你需要什么。
我应该说，尽管 GCM 具有加密和消息完整性，但它是一个非常脆弱的设计：如果你重新使用 IV，你就完蛋了——攻击者可以恢复你的密钥。其他设计不那么脆弱，所以我个人害怕根据我在实践中看到的糟糕加密代码的数量来推荐 GCM。
如果你需要消息完整性和加密两者，你可以结合两种算法：通常我们看到 CBC 和 HMAC，但没有理由将自己绑定到 CBC。重要的是要先加密，然后 MAC 加密内容，而不是反过来。此外，IV 需要成为 MAC 计算的一部分。
我不知道知识产权问题。
现在来看看 Rogaway 教授的好东西：
ECB：一种分组密码，该模式通过分别加密每个 n 位片段来加密 n 位的倍数的消息。安全属性很弱，该方法在块位置和时间上泄漏块的相等性。具有相当大的遗留价值，并且具有作为其他方案的构建块的价值，但该模式本身并不能实现任何普遍期望的安全目标，必须非常谨慎地使用；ECB不应被视为一种“通用”的保密模式。
CBC : 一种基于 IV 的加密方案，该模式作为概率加密方案是安全的，实现与随机位不可区分，假设为随机 IV。如果 IV 只是一个 nonce，或者它是在该方案使用的相同密钥下加密的 nonce ，则无法实现机密性，正如标准错误地建议的那样。密文具有高度可塑性。没有选择密文攻击 (CCA) 安全性。对于许多填充方法，如果存在正确的填充预言，机密性将被丧失。由于本质上是串行的，因此加密效率低下。广泛使用，该模式的仅限隐私的安全属性导致频繁的误用。可用作 CBC-MAC 算法的构建块。我无法确定与 CTR 模式相比的重要优势。
CFB：一种基于IV的加密方案，该模式作为概率加密方案是安全的，假设随机IV，实现与随机位的不可区分性。如果 IV 是可预测的，或者它是由在方案使用的相同密钥下加密的 nonce 生成的，则无法实现机密性，正如标准错误地建议的那样。密文是可延展的。没有 CCA 安全性。由于本质上是串行的，因此加密效率低下。方案取决于参数 s，1 ≤ s ≤ n，通常 s = 1 或 s = 8。需要一次分组密码调用来仅处理 s 位效率低下。该模式实现了一个有趣的“自同步”特性；在密文中插入或删除任意数量的 s 位字符只会暂时中断正确的解密。
OFB：一种基于IV的加密方案，该模式作为概率加密方案是安全的，实现与随机位不可区分，假设是随机IV。如果 IV 是 nonce，则无法实现机密性，尽管 IV 的固定序列（例如，计数器）确实可以正常工作。密文具有高度可塑性。没有 CCA 安全性。由于本质上是串行的，因此加密和解密效率低下。本机加密任何位长度的字符串（不需要填充）。我无法确定与 CTR 模式相比的重要优势。
CTR：一种基于 IV 的加密方案，该模式实现了与假设 nonce IV 的随机位的不可区分性。作为一种安全的基于 nonce 的方案，该模式也可以用作概率加密方案，具有随机 IV。如果随机数在加密或解密中被重用，则隐私完全失败。该模式的并行性通常使其速度更快，在某些设置中比其他机密模式更快。认证加密方案的重要组成部分。总体而言，通常是实现仅隐私加密的最佳和最现代的方式。
XTS：一种基于 IV 的加密方案，该模式通过将可调整的分组密码（作为强 PRP 安全）应用于每个 n 位块来工作。对于长度不能被 n 整除的消息，最后两个块被特殊处理。该模式唯一允许的用途是加密块结构存储设备上的数据。底层 PRP 的狭窄宽度和部分最终区块的不良处理是问题。比（宽块）PRP 安全分组密码更有效但不太理想。
ALG1-6：MAC 的集合，所有这些都基于 CBC-MAC。方案太多。有些作为 VIL PRF 可证明是安全的，有些作为 FIL PRF，有些则没有可证明的安全性。一些计划承认破坏性攻击。有些模式已经过时了。对于具有它的模式，密钥分离没有得到充分关注。不应大量采用，但可以选择性地选择“最佳”方案。也可以不采用这些模式，而支持 CMAC。一些 ISO 9797-1 MAC 被广泛标准化和使用，尤其是在银行业。该标准的修订版 (ISO/IEC FDIS 9797-1:2010) 即将发布 [93]。
CMAC：基于 CBC-MAC 的 MAC，该模式可证明是安全的（直到生日界限）作为（VIL）PRF（假设底层块密码是一个好的 PRP）。对于基于 CBCMAC 的方案而言，开销基本上是最小的。在某些应用程序域中固有的串行性质是一个问题，并且与 64 位分组密码一起使用将需要偶尔重新键入密钥。比 ISO 9797-1 的 MAC 集合更干净。
HMAC：基于加密散列函数而不是块密码的 MAC（尽管大多数加密散列函数本身是基于块密码的）。机制享有强大的可证明安全界限，尽管不是来自首选假设。文献中的多个密切相关的变体使了解已知内容变得复杂。从未提出过破坏性攻击。广泛标准化和使用。
GMAC：基于随机数的 MAC，是 GCM 的一个特例。继承了 GCM 的许多优点和缺点。但是对于 MAC 来说，nonce 要求是不必要的，在这里它几乎没有什么好处。如果标签被截断为 ≤ 64 位并且解密范围不受监控和缩减，则实际攻击。nonce-reuse 完全失败。如果采用 GCM，则无论如何使用都是隐含的。不推荐单独标准化。
CCM：一种基于 nonce 的 AEAD 方案，它结合了 CTR 模式加密和原始 CBC-MAC。本质上是串行的，在某些情况下会限制速度。假设底层块密码是一个好的 PRP，可证明是安全的，具有良好的界限。笨拙的建筑，显然可以完成这项工作。比 GCM 更容易实现。可用作基于 nonce 的 MAC。广泛标准化和使用。
GCM：一种基于 nonce 的 AEAD 方案，结合了 CTR 模式加密和基于 GF(2128) 的通用散列函数。对于某些实现环境具有良好的效率特性。假设标签截断最少，良好的可证明安全的结果。存在大量标签截断时的攻击和可证明的安全边界差。可以用作基于 nonce 的 MAC，然后称为 GMAC。允许 96 位以外的随机数的可疑选择。建议将随机数限制为 96 位，将标签限制为至少 96 位。广泛标准化和使用。
您可能希望根据广泛可用的内容进行选择。我有同样的问题，这是我有限研究的结果。
硬件限制
STM32L (low energy ARM cores) from ST Micro support ECB, CBC,CTR GCM
CC2541 (Bluetooth Low Energy) from TI supports ECB, CBC, CFB, OFB, CTR, and CBC-MAC
开源限制
Original rijndael-api source - ECB, CBC, CFB1
OpenSSL - command line CBC, CFB, CFB1, CFB8, ECB, OFB
OpenSSL - C/C++ API CBC, CFB, CFB1, CFB8, ECB, OFB and CTR
EFAES lib [1] - ECB, CBC, PCBC, OFB, CFB, CRT ([sic] CTR mispelled)
OpenAES [2] - ECB, CBC
[1] http://www.codeproject.com/Articles/57478/A-Fast-and-Easy-to-Use-AES-Library
您是否已开始阅读有关 Wikipedia- Block cipher mode of operation的信息？然后按照 Wikipedia 上的参考链接访问NIST：Recommendation for Block Cipher Modes of Operation。
我知道一个方面：虽然 CBC 通过更改每个块的 IV 来提供更好的安全性，但它不适用于随机访问的加密内容（如加密硬盘）。
因此，对顺序流使用 CBC（和其他顺序模式），对随机访问使用 ECB。