在哪种情况下首选哪个？

我希望看到各种模式的评估标准的清单，也许还要讨论每个标准的适用性。

例如，我认为准则之一是用于加密和解密的“代码大小”，这对于诸如802.11网络适配器之类的微代码嵌入式系统很重要。如果实现CBC所需的代码比CTR所需的代码小得多（我不知道这是真的，这只是一个例子），那么我可以理解为什么使用较小代码的模式是首选。但是，如果我编写的是在服务器上运行的应用程序，并且我所使用的AES库无论如何都实现CBC和CTR，则此标准无关紧要。

明白我的意思是“评估标准列表和每个标准的适用性”吗？

这实际上与编程无关，但与算法有关。

• 如果使用同一密钥加密多个数据块，则不应使用ECB。

• CBC，OFB和CFB相似，但是OFB / CFB更好，因为您只需要加密而不需要解密，这样可以节省代码空间。

• 如果您想要良好的并行化（即速度），请使用CTR，而不是CBC / OFB / CFB。

• 如果您正在编码随机可访问的数据（例如硬盘或RAM），则XTS模式是最常见的。

• 到目前为止，OCB是最好的模式，因为它允许一次通过加密和身份验证。但是，它在美国有专利。

您真正需要知道的唯一一件事是，除非仅加密1个块，否则不使用ECB。如果要加密随机访问的数据而不是流，则应使用XTS。

• 您每次加密时都应该始终使用唯一的IV，并且它们应该是random。如果您不能保证它们是随机的，请使用OCB，因为它只需要一个随机数，而不是IV，并且会有明显的不同。一个随机数不降的安全性，如果人们可以猜测下一个，一个IV可能会导致此问题。

如果您无法解决自己的加密问题，请多加考虑

这件事的丑陋事实是，如果您提出这个问题，您可能将无法设计和实现安全的系统。

让我说明一下我的观点：假设您正在构建Web应用程序，并且需要存储一些会话数据。您可以为每个用户分配一个会话ID，并将会话数据存储在将会话ID映射到会话数据的哈希映射中的服务器上。但是随后您必须处理服务器上的这种令人讨厌的状态，如果在某个时候您需要多个服务器，那么事情将会变得混乱。因此，您可以将会话数据存储在客户端的Cookie中。当然，您将对其进行加密，以使用户无法读取和操纵数据。那么您应该使用哪种模式？来到这里，您会读到最重要的答案（对不起，将您挑出myforwik）。第一个涵盖的内容-ECB-不适用于您，您想要加密多个块，第二个内容-CBC-听起来不错，您不需要CTR的并行性，您不需要随机访问，因此，没有XTS和专利是PITA，因此也没有OCB。使用您的加密库，您意识到您需要一些填充，因为您只能加密块大小的倍数。你选PKCS7，因为它是在一些严格的加密标准中定义的。读到某个地方，如果将CBC 与随机IV和安全的分组密码一起使用，则证明 CBC是安全的，即使您将敏感数据存储在客户端，也可以放心使用。

在您的服务确实增长到可观的规模之后的数年，IT安全专家会以负责任的方式与您联系。她告诉您可以使用padding oracle攻击来解密所有cookie ，因为如果padding被破坏，您的代码将产生一个错误页面。

这不是一种假设的情况： 直到几年前，Microsoft才在ASP.NET中存在此确切漏洞。

问题在于，密码技术存在很多陷阱，建立一个对外行来说看起来很安全但对知识渊博的攻击者来说却很难破解的系统非常容易。

如果需要加密数据该怎么办

对于实时连接，请使用TLS（请务必检查证书的主机名和颁发者链）。如果您不能使用TLS，请寻找系统必须为任务提供的最高级别的API，并确保您了解它提供的保证，以及更重要的是它不能保证的保证。对于上面的示例，像Play这样的框架提供了客户端存储功能，但是一段时间后它不会使存储的数据无效，并且，如果您更改了客户端状态，攻击者可以在不注意的情况下恢复先前的状态。

如果没有可用的高级抽象，请使用高级密码库。最著名的例子是NaCl，具有许多语言绑定的可移植实现是Sodium。使用这样的库，您不必关心加密模式等，但是与使用更高级别的抽象（例如，从未两次使用随机数）相比，您必须更加小心使用细节。

如果由于某种原因（例如，由于您需要以特定方式与现有系统进行交互）而无法使用高级密码库，则无法彻底地对自己进行教育。我建议阅读Ferguson，Kohno和Schneier撰写的《密码学工程》。请不要自欺欺人地相信您可以在没有必要背景的情况下构建安全的系统。密码学非常微妙，几乎不可能测试系统的安全性。

模式比较

仅加密：

• 需要填充的模式：与示例中一样，填充通常很危险，因为它增加了填充oracle攻击的可能性。最简单的防御方法是在解密之前对每条消息进行身份验证。见下文。
  • ECB独立地加密每个数据块，并且相同的明文块将产生相同的密文块。在ECB Wikipedia页面上查看ECB加密的Tux图像，以了解为什么这是一个严重的问题。我不知道任何可以接受ECB的用例。
  • CBC具有IV，因此每次对消息进行加密时都需要随机性，更改消息的一部分需要在更改后重新加密所有内容，一个密文块中的传输错误会完全破坏明文并更改下一个块的解密，即解密可以并行化/不能加密，明文在一定程度上具有延展性- 这可能是一个问题。
• 流密码模式：这些模式会生成伪随机数据流，该数据可能会或可能不会依赖于明文。通常与流密码类似，将生成的伪随机流与明文进行XOR运算以生成密文。由于您可以根据需要使用任意数量的随机流，因此根本不需要填充。这种简单性的缺点是加密是完全可延展的，意味着解密者可以以喜欢的任何方式更改解密，例如明文p1，密文c1和伪随机流r，并且攻击者可以选择差异d，使得密文c2 =c1⊕d是p2 =p1⊕d，因为p2 =c2⊕r=（c1⊕d）⊕r = d⊕（c1⊕r）。同样，相同的伪随机流绝不能像两个密文c1 =p1⊕r和c2 =p2⊕r一样使用两次，攻击者可以将两个明文的xor计算为c1⊕c2=p1⊕r⊕p2⊕r= p1⊕p2。这也意味着，如果原始消息可能已被攻击者获取，则更改消息需要完全重新加密。以下所有所有的蒸汽密码模式仅需要块密码的加密操作，因此，在不同的密码环境下，这可能会节省一些（硅或机器代码）空间，具体取决于密码。
  • CTR很简单，它创建了一个独立于明文的伪随机流，通过从不同的nonce / IV进行计数获得不同的伪随机流，将它们乘以最大消息长度，从而避免重叠，使用nonces消息加密是没有消息随机性，解密和加密可并行完成，传输错误仅影响错误的位，仅此而已
  • OFB还创建了一个独立于明文的伪随机流，通过为每个消息以不同的随机数或随机IV开头来获得不同的伪随机流，加密和解密都无法并行化，就像使用CCC使用随机数消息加密是可能的，而无需对每个消息进行加密与CTR传输错误一样，随机性只会影响错误的位，仅此而已
  • CFB的伪随机流取决于明文，每条消息都需要不同的随机数或随机IV，例如CTR和OFB使用随机数消息加密是可能的，而没有每个消息的随机性，解密是可并行化的/加密不是，传输错误完全销毁以下块，但仅影响当前块中的错误位
• 磁盘加密模式：这些模式专用于加密文件系统抽象之下的数据。出于效率方面的考虑，更改光盘上的某些数据仅要求最多重写一个光盘块（512字节或4kib）。它们超出了此答案的范围，因为它们的使用场景与其他场景截然不同。除块级光盘加密外，请勿将它们用于其他任何用途。一些成员：XEX，XTS，LRW。

认证加密：

为了防止填充oracle攻击和对密文的更改，可以在密文上计算消息认证码（MAC），并且只有在未对其进行篡改的情况下才能对其进行解密。这称为crypto-then-mac，应优先于其他任何顺序。除了极少数用例以外，真实性与机密性同样重要（后者是加密的目的）。经过身份验证的加密方案（带有关联数据（AEAD））将加密和身份验证的两部分过程组合到一个块密码模式中，该过程还会在过程中生成身份验证标签。在大多数情况下，这可以提高速度。

• CCM是CTR模式和CBC-MAC的简单组合。每个块使用两个块密码加密非常慢。
• OCB速度更快，但是受到专利的限制。但是，对于免费（如自由）或非军事软件，专利持有人已授予了免费许可。
• GCM是CTR模式和GHASH的非常快速但可以说是复杂的组合，GHASH是Galois字段上具有2 ^ 128个元素的MAC。英特尔为加快GHASH计算速度而推出的一条特殊指令反映了它在TLS 1.2等重要网络标准中的广泛使用。

建议：

考虑到身份验证的重要性，我建议在大多数情况下（磁盘加密除外）使用以下两种块密码模式：如果通过非对称签名对数据进行身份验证，请使用CBC，否则请使用GCM。

一个正式的分析已经由Phil Rogaway在2011年已经完成，在这里。1.6节提供了一个摘要，我在此处进行了总结，并以粗体显示了自己的重点（如果您不耐烦，则建议使用CTR模式，但建议您阅读以下有关消息完整性与加密的段落）。

请注意，其中大多数要求IV是随机的，这意味着不可预测，因此应使用加密安全性来生成。但是，有些仅要求“立即”，即不要求该属性，而仅要求不重复使用。因此，依赖于随机数的设计比不依赖随机数的设计更不容易出错（并且相信我，我已经看到很多情况下都没有通过适当的IV选择来实现CBC）。因此，您会看到Rogaway说“当IV是随机数时无法实现机密性”之类的东西时，我已经加了粗体，这意味着，如果您选择IV加密安全（无法预测），那么就没问题了。但是，如果不这样做，那么您将失去良好的安全性。 切勿将IV重新用于任何这些模式。

同样，了解消息完整性和加密之间的区别也很重要。加密隐藏数据，但是攻击者可能能够修改加密的数据，并且如果您不检查消息的完整性，则结果可能会被您的软件接受。尽管开发人员会说“但解密后修改后的数据将作为垃圾返回”，但是优秀的安全工程师会发现垃圾在软件中引起不良行为的可能性，然后他将分析变成真正的攻击。我已经看到了许多使用加密的情况，但是真正需要的是消息完整性，而不是加密。了解您的需求。

我应该说，尽管GCM同时具有加密和消息完整性，但它是一个非常脆弱的设计：如果重新使用IV，您将被搞砸了-攻击者可以恢复您的密钥。其他设计不那么脆弱，因此我个人恐怕会根据我在实践中看到的不良加密代码的数量来推荐GCM。

如果同时需要消息完整性和加密，则可以结合使用两种算法：通常我们看到带有HMAC的CBC，但没有理由将自己束缚于CBC。重要的是要先加密，然后再将加密的内容MAC，而不是相反。此外，IV必须是MAC计算的一部分。

我不了解IP问题。

现在来看看Rogaway教授的好东西：

分组密码模式，加密但不保证消息完整性

ECB：分组密码，该模式通过分别加密每个n位片段来加密n位的倍数的消息。安全性很弱，该方法会在块的位置和时间上泄漏块的相等性。具有相当大的传统价值，并具有作为其他方案的基础的价值，但是该模式本身并不能实现任何普遍希望的安全目标，必须谨慎使用；欧洲央行不应被视为“通用”保密模式。

CBC：一种基于IV的加密方案，该模式作为概率加密方案是安全的，假设使用随机IV，则与随机位无法区分。如果IV只是一个随机数，或者它不是该计划使用的相同密钥下加密的随机数（如标准错误地建议这样做），则无法实现机密性。密文具有很高的延展性。没有选择的密文攻击（CCA）安全性。如果存在针对许多填充方法的正确填充预言，则将失去机密性。固有的串行加密效率低下。该模式仅用于隐私的安全属性被广泛使用，导致频繁滥用。可用作CBC-MAC算法的构件。与CTR模式相比，我没有发现任何重要的优势。

CFB：一种基于IV的加密方案，该模式作为概率加密方案是安全的，假定为随机IV，则与随机位无法区分。如果IV是可预测的，则不能实现机密性；或者，如果该IV是由该计划所使用的相同密钥加密的随机数来实现的，则该标准将不正确地建议这样做。密文具有延展性。没有CCA安全性。固有的串行加密效率低下。方案取决于参数s，1≤s≤n，通常为s = 1或s =8。对于需要一个块密码调用仅处理s位的效率较低。该模式实现了一个有趣的“自同步”属性。在密文中插入或删除任意数量的s位字符只会暂时破坏正确的解密。

OFB：基于IV的加密方案，该模式作为概率加密方案是安全的，假设使用随机IV，则与随机位无法区分。如果IV是随机数，则无法实现机密性，尽管IV的固定序列（例如计数器）确实可以正常工作。密文具有很高的延展性。没有CCA安全性。加密和解密由于固有的串行性而效率低下。本机加密任何位长的字符串（无需填充）。与CTR模式相比，我没有发现任何重要的优势。

CTR：一种基于IV的加密方案，该模式与随机数（假定为随机数IV）实现了不可区分性。作为基于安全随机数的方案，该模式还可以用作具有随机IV的概率加密方案。如果随机数被重新用于加密或解密，则隐私完全失败。与其他机密性模式相比，该模式的可并行性通常使它在某些设置中更快一些。身份验证加密方案的重要组成部分。总体而言，通常是实现仅隐私加密的最好和最现代的方式。

XTS：一种基于IV的加密方案，该模式通过对每个n位块应用可调整的分组密码（作为强PRP安全）来工作。对于长度不能被n整除的消息，将特别对待最后两个块。该模式唯一允许的用途是对块结构存储设备上的数据进行加密。底层PRP的宽度较窄，对最终嵌段的处理不善是个问题。比（宽块）PRP安全的分组密码更有效，但较不理想。

MAC（消息完整性，但不加密）

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 MACs清洁。

HMAC：基于加密哈希函数而不是分组密码的MAC（尽管大多数加密哈希函数本身都是基于分组密码的）。该机制享有可证明的安全性界限，尽管并非来自首选假设。文献中的多个密切相关的变体使人们对已知的事物的理解变得复杂。从未提出过破坏性攻击的建议。广泛标准化和使用。

GMAC：基于随机数的MAC，是GCM的特例。继承了GCM的许多优缺点。但是，对于MAC而言，非随机数需求是不必要的，并且在这里它几乎没有收益。如果标签被截断到≤64位并且解密的范围未受到监控和缩减，则会受到实际攻击。随机数重用完全失败。如果采用GCM，则使用是隐式的。不建议用于单独的标准化。

经过身份验证的加密（加密和消息完整性）

CCM：结合了CTR模式加密和原始CBC-MAC的基于现时的AEAD方案。本质上是串行的，在某些情况下限制了速度。假设基础分组密码是一个好的PRP，则可以很好地保证安全且具有良好的边界。笨拙的施工证明可以完成这项工作。比GCM易于实现。可用作基于随机数的MAC。广泛标准化和使用。

GCM：一种基于随机数的AEAD方案，结合了CTR模式加密和基于GF（2128）的通用哈希函数。在某些实施环境中具有良好的效率特征。假设标签截断最少，可证明安全性良好。存在大量标签截断的攻击和可证明的安全性差。可用作基于随机数的MAC，然后称为GMAC。允许使用非96位随机数的可疑选择。建议将随机数限制为96位，标记至少为96位。广泛标准化和使用。

1. 除了欧洲央行以外。
2. 如果使用CTR，则必须为每条消息使用不同的IV，否则，攻击者最终将能够获取两个密文并获得合并的未加密明文。原因是CTR模式本质上将分组密码转换为流密码，并且流密码的第一个规则是永远不要两次使用相同的Key + IV。
3. 实施这些模式的难度实际上并没有多大差异。某些模式仅要求块密码在加密方向上运行。但是，包括AES在内的大多数分组密码都不需要花费更多的代码来实现解密。
4. 对于所有密码模式，如果您的消息的前几个字节可能是相同的，并且您不想让攻击者知道这一点，则对每个消息使用不同的IV至关重要。

您是否已从Wikipedia上的相关信息开始阅读- 分组密码操作模式？然后，按照Wikipedia上的参考链接到达NIST：分组密码操作模式建议。

您可能要根据广泛使用的内容进行选择。我有同样的问题，这是我有限的研究结果。

硬件限制

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

[2] https://openaes.googlecode.com/files/OpenAES-0.8.0.zip

我知道一个方面：尽管CBC通过更改每个块的IV可以提供更好的安全性，但它不适用于随机访问的加密内容（如加密硬盘）。

因此，对顺序流使用CBC（和其他顺序模式），对随机访问使用ECB。