如何selectAESencryption模式（CBC ECB CTRB OCB CFB）？
在哪些情况下，哪些人更喜欢？
我希望看到不同模式的评估标准清单，也许是讨论每个标准的适用性。
例如，我认为encryption和解密的标准之一就是“代码的大小”，这对微码embedded式系统（如802.11networking适配器）很重要。 如果实现CBC所需的代码比CTR所需要的代码小得多（我不知道这是真的，这只是一个例子），那么我可以理解为什么使用较小代码的模式将是首选。 但是，如果我正在编写一个在服务器上运行的应用程序，而且我使用的AES库同时实现了CBC和CTR，那么这个标准是无关紧要的。
看看我的意思是“每个标准的评估标准和适用性列表”？
这不是真正的编程相关，而是algorithm相关的。
-
如果使用相同的密钥encryption多个数据块，则不应使用ECB。
-
CBC，OFB和CFB是相似的，但OFB / CFB更好，因为你只需要encryption而不是解密，这样可以节省代码空间。
-
如果您想要良好的并行化（即速度），而不是CBC / OFB / CFB，则使用CTR。
-
XTS模式是最常见的，如果你编码随机访问的数据（如硬盘或RAM）。
-
OCB是迄今为止最好的模式，因为它允许一次性encryption和authentication。 不过在美国有专利。
你唯一需要知道的是ECB不能被使用，除非你只encryption1块。 如果您正在encryption随机访问的数据而不是stream，则应使用XTS。
- 你应该总是使用独特的四，每次你encryption，他们应该是随机的。 如果你不能保证他们是随机的，使用OCB，因为它只需要一个随机数，而不是一个IV，并且有一个明显的区别。 一个随机数不会降低安全性，如果人们可以猜测下一个，IV可以导致这个问题。
简介：这个答案部分是对我在[encryption]标签下看到的很多问题的回应，它显示了人们部署完全不安全的代码。 为了解决这些程序员的问题，我写了以下的开头句子，打算在应用程序受到攻击之前，重新思考他们的encryption方法 。 如果你在学习的过程中，那太棒了！ 我们需要更多具有密码学背景知识的程序员。 继续询问，并添加一个沉默的“呢！” 到我的开头：
如果您需要提出这个问题，您可能对密码学知识不够，无法实现安全的系统。
我知道这听起来很刺耳，所以让我来说明一下我的观点：想象一下，您正在构build一个Web应用程序，并且需要存储一些会话数据。 您可以为每个用户分配一个会话ID，并将会话数据存储在服务器中的哈希映射会话ID到会话数据中。 但是，那么你必须在服务器上处理这个烦人的状态，如果在某个时候你需要多个服务器，情况就会变得混乱。 所以相反，你有想法将会话数据存储在客户端的cookie中。 您当然会encryption，所以用户无法读取和操作数据。 那么你应该使用什么模式？ 来到这里，你读了最高的答案（对不起，你挑出myforwik）。 第一个涵盖 – 欧洲央行 – 不是你，你想encryption多块，下一个 – CBC – 听起来不错，你不需要CTR的并行性，你不需要随机访问，所以没有XTS和专利是PITA，所以没有OCB。 使用你的encryption库，你意识到你需要一些填充，因为你只能encryption块大小的倍数。 您selectPKCS7是因为它是在一些严格的密码学标准中定义的。 在阅读某个地方CBC certificate是安全的，如果使用随机的IV和安全的分组密码，即使您将敏感数据存储在客户端，您也可以放心。
在您的服务确实已经达到相当规模之后的几年之后，IT安全专家会以负责任的方式与您联系。 她告诉你，她可以使用padding oracle攻击解密所有的cookie，因为如果填充被破坏，你的代码会产生一个错误页面。
这不是一个假设的情况： 直到几年前，微软在ASP.NET中才有这个确切的缺陷。
问题是在密码学方面存在很多缺陷，build立一个外行看起来很安全的系统是非常容易的，但是对于一个知识渊博的攻击者来说却是微不足道的。
如果您需要encryption数据，该怎么做
对于实时连接，使用TLS（确保检查证书的主机名和发行者链）。 如果您不能使用TLS，请查找系统为您的任务提供的最高级别的API，并确保您了解其提供的保证，更重要的是它不保证的。 对于上面的例子，像Play这样的框架提供了客户端存储function ，但是在一段时间后它不会使存储的数据无效，而且如果你改变了客户端的状态，攻击者就可以在没有注意的情况下恢复以前的状态。
如果没有可用的高级抽象，则使用高级encryption库。 一个突出的例子是NaCl和许多语言绑定的便携式实现是钠 。 使用这样一个库，你不必关心encryption模式等，但你必须更加注意使用细节，而不是更高层次的抽象，就像从不使用nonce两次。
如果由于某种原因，您不能使用高级encryption库，例如因为您需要以特定的方式与现有系统进行交互，则无法彻底教育自己。 我推荐阅读Ferguson，Kohno和Schneier的Cryptography Engineering 。 请不要自欺欺人地相信，如果没有必要的背景，你可以build立一个安全的系统。 密码学是非常微妙的，几乎不可能testing系统的安全性。
为了教育目的，比较模式
仅encryption：
- 需要填充的模式 ：就像在这个例子中一样，填充通常是很危险的，因为它可以填充oracle攻击的可能性。 最简单的防御措施是在解密之前validation每条消息。 见下文。
- ECB独立encryption每个数据块，同一个明文块会产生相同的密文块。 看看欧洲央行维基百科页面上的ECBencryptionTux图像，看看为什么这是一个严重的问题。 我不知道欧洲央行可以接受的任何用例。
- CBC有一个IV，因此每次消息被encryption时需要随机性，改变一部分消息需要在改变之后重新encryption所有东西，在一个密文块中的传输错误完全破坏了明文并且改变了下一个块的解密，解密可以并行/encryption不能，明文在一定程度上是可延展的 – 这可能是一个问题 。
- 数据stream密码模式 ：这些模式产生一个伪随机数据stream，可能取决于明文，也可能不取决于明文。 与通常的stream密码类似，所生成的伪随机stream与明文异或以生成密文。 正如你可以使用任意数量的随机stream，你根本不需要填充。 这种简单性的缺点在于encryption是完全可延展的 ，这意味着解密可以由攻击者以他喜欢的任何方式改变，如对于明文p1，密文c1和伪随机streamr，并且攻击者可以select差异d密文c 2 = c 1 d的解密为p 2 = p 1 dd，因为p 2 = c 2 r 2 =（c 1⊕d）⊕r= d⊕（c 1⊕r）。 对于两个密文c1 =p1⊕r和c2 =p2⊕r，同样的伪随机stream也不能使用两次，攻击者可以计算两个明文的异或为c1⊕c2=p1⊕r⊕p2⊕r= p1⊕p2。 这也意味着，如果原始消息可能已经被攻击者获得，则改变消息需要完全重新encryption。 所有下面的蒸汽密码模式只需要分组密码的encryption操作，所以根据密码，这可能在极其狭窄的环境中节省一些（硅或机器代码）空间。
- CTR是简单的，它创build一个独立于明文的伪随机stream，通过从不同的nonces / IVs计数得到不同的伪随机stream，乘以最大消息长度以防止重叠，使用nonces消息encryption可能没有每个消息的随机性，解密和encryption完成并行化，传输错误只影响错误的比特，仅此而已
- OFB还创build独立于明文的伪随机stream，通过以每个消息的不同随机数或随机IV开始获得不同的伪随机stream，因为CTR使用随机消息encryption，而没有每个消息的随机性，解密是可并行化的/encryption的并不像CTR传输错误一样只影响错误的位数，
- CFB的伪随机stream取决于明文，每个消息需要一个不同的随机数或随机数Ⅳ，就像使用CTR和OFB使用随机消息encryption是可能的，而不是每个消息的随机性，解密是可并行/encryption不是，完全传输错误销毁下面的块，但只影响当前块中的错误位
- 磁盘encryption模式 ：这些模式专门用于encryption文件系统抽象下的数据。 出于效率原因，更改光盘上的某些数据只需要重写最多一个光盘块（512字节或4kib）。 他们超出了这个答案的范围，因为他们的使用情况大大不同。 除块级光盘encryption之外，不要使用它们 。 有些成员：XEX，XTS，LRW。
经过身份validation的encryption：
为了防止填充oracle攻击和密文变化，可以在密文上计算一个消息authentication码 （MAC），只有在密文没有被篡改的情况下才能解密。 这叫做encrypt-then-mac， 应该比任何其他命令更受欢迎 。 除了非常less的用例外，真实性与保密性（后者是encryption的目的）一样重要。 经过authentication的encryptionscheme（带有相关数据（AEAD））将encryption和authentication的两部分过程组合到一个分组密码模式中，该模式也在过程中产生authentication标签。 在大多数情况下，这会导致速度的提高。
- CCM是CTR模式和CBC-MAC的简单组合。 每块使用两个分组密码encryption是非常缓慢的。
- OCB速度更快，但受到专利的困扰。 尽pipe免费（如在自由）或非军事软件，专利持有人已经授予免费许可 。
- GCM是一种速度非常快但可以说是CTR模式和GHASH的复杂组合，它是2 ^ 128元素的伽罗瓦域上的MAC。 它在TLS1.2等重要networking标准中的广泛使用，反映了英特尔为加速GHASH计算而推出的特殊指令 。
build议：
考虑到身份validation的重要性，对于大多数使用情况（除了磁盘encryption目的），我build议使用以下两种分组密码模式：如果数据通过不对称签名进行身份validation，则使用CBC，否则使用GCM。
- 除了欧洲央行。
- 如果使用CTR，则必须为每条消息使用不同的IV，否则最终攻击者能够获取两个密文并导出一个未encryption的明文组合。 原因在于CTR模式本质上是将分组密码转换为stream密码，而stream密码的第一个规则是永远不会使用相同的Key + IV两次。
- 模式的实施难度确实不大。 有些模式只需要分组密码在encryption方向上操作。 但是，包括AES在内的大多数分组密码不需要太多的代码来实现解密。
- 对于所有密码模式，如果您的消息在前几个字节中可能相同，并且您不希望攻击者知道这一点，则为每条消息使用不同的IV是很重要的。
Phil Rogaway在2011年进行了正式的分析。 1.6节给出了我在这里抄录的摘要，加上我自己的强调（如果你不耐烦，那么他的build议是使用CTR模式，但我build议你阅读我的关于消息完整性和下面的encryption的段落）。
请注意，其中大部分要求IV是随机的，这意味着不可预测，因此应该使用密码安全性生成。 然而，有些只需要一个“nonce”，它不要求这个属性，而只是要求它不被重用。 因此，依赖于随机数的devise比没有devise的devise更容易出错（并且相信我，在许多情况下CBC没有通过适当的IVselect实现）。 所以当Rogaway说“当IV是一个随机数时不能实现保密性”时，你会看到我加了一个大胆的字样，这意味着如果你select你的IVencryption安全（不可预测的），那就没有问题了。 但是，如果你不这样做，那么你正在失去良好的安全属性。 切勿重复使用任何这些模式的IV 。
此外，了解消息完整性和encryption之间的差异也很重要。 encryption隐藏数据，但是攻击者可能会修改encryption的数据，如果不检查消息的完整性，结果可能会被软件接受。 虽然开发者会说“但是修改后的数据会在解密后回到垃圾箱”，一个好的安全工程师会发现垃圾在软件中造成不良行为的可能性，然后他会把这个分析变成真正的攻击。 我见过很多使用encryption的情况，但是真正需要比encryption更多的信息完整性。 了解你需要什么。
我应该说，尽pipeGCM具有encryption和消息完整性，但它是一个非常脆弱的devise：如果您重新使用IV，那么您就被搞砸了 – 攻击者可以恢复您的密钥。 其他的devise不那么脆弱，所以我个人恐怕根据我在实践中看到的糟糕的encryption代码的数量来推荐GCM。
如果你同时需要消息完整性和encryption，你可以结合两种algorithm：通常我们看到CBC和HMAC，但没有理由把自己绑定到CBC。 要知道的重要的事情是先encryption，然后MACencryption的内容 ，而不是反过来。 另外，IV需要成为MAC计算的一部分。
我不知道知识产权问题。
现在来看Rogaway教授的好东西：
分组密码模式，encryption但不是消息完整性
ECB ：一种密码锁，该模式通过分别对每个n比特片段进行encryption来encryptionn比特的倍数的消息。 安全属性很弱 ，这种方法会在块的位置和时间上泄漏块的相等性。 它具有相当的传统价值，并且作为其他scheme的基石，但是这种方式本身并没有达到任何普遍理想的安全目标，必须谨慎使用。 欧洲央行不应被视为“通用”保密模式 。
CBC ：基于IV的encryptionscheme，该模式作为概率encryptionscheme是安全的，假定随机IV实现与随机比特的不可区分性。 如果IV仅仅是一个随机数 ，并且如果它是在该scheme使用的相同密钥下encryption的随机数 ，那么保密是不能实现的 ，正如标准错误地暗示的那样。 密文是高度可塑的。 没有select的密文攻击（CCA）安全性。 在许多填充方法的正确填充oracle的情况下，保密性将被放弃。 从本质上讲，encryption效率低下。 广泛使用，模式的隐私安全属性导致频繁的滥用。 可以用作CBC-MACalgorithm的构build块。 我可以确定CTR模式没有什么重要的优势。
CFB ：基于IV的encryptionscheme，该模式作为概率encryptionscheme是安全的，假定随机IV，实现与随机比特的不可区分性。 如果IV是可预测的 ，那么保密性是不能实现的 ，如果是由该计划使用的相同密钥所encryption的随机数制成，则保密性不成立 ，正如标准错误地暗示的那样。 密文是可延展的。 没有CCA安全。 从本质上讲，encryption效率低下。 scheme取决于参数s，1≤s≤n，典型地s = 1或s = 8。对于需要一个块密码调用来仅处理s比特是不够的。 该模式实现了一个有趣的“自我同步”属性; 在密文中插入或删除任何数量的s位字符只会暂时中断正确的解密。
OFB ：基于IV的encryptionscheme，该模式作为概率encryptionscheme是安全的，假设随机IV，实现与随机比特的不可区分性。 如果IV是一个随机数，保密是不能实现的，尽pipe一个固定的IV（例如，一个计数器）序列工作正常。 密文是高度可塑的。 没有CCA安全。 encryption和解密从本质上讲是无效的。 本地encryption任何位长的string（不需要填充）。 我可以确定CTR模式没有什么重要的优势。
CTR ：基于IV的encryptionscheme，该模式假设随机数IV与随机比特实现不可区分性。 作为一个安全的nonce为基础的scheme，该模式也可以作为一个概率encryptionscheme，随机四。 如果一个随机数重用于encryption或解密，则完全失去隐私。 模式的可并行性通常使其在某些设置中比其他机密模式更快。 authenticationencryptionscheme的重要组成部分。 总体而言，通常是实现隐私专用encryption的最佳和最现代的方式。
XTS ：基于IV的encryptionscheme，该模式通过对每个n位块应用可调节的块密码（作为强PRP安全）来工作。 对于长度不能被n整除的消息，最后两个块被专门处理。 唯一允许使用的模式是用于encryption块结构存储设备上的数据。 底层PRP的窄宽度和部分最终块的差处理是问题。 比（宽块）PRP安全的块密码更高效但不太理想。
MAC（消息完整性但不encryption）
ALG1-6 ：一组MAC，全部基于CBC-MAC。 太多的计划。 有些可证实为VIL PRF，有些可能是FIL PRF，有些则没有可certificate的安全性。 有些计划承认破坏性攻击。 一些模式是过时的。 密钥分离对于拥有它的模式来说是不够的。 不应该集体采用，但有select地select“最好”的scheme是可能的。 没有采用这些模式也是可以的，有利于CMAC。 一些ISO 9797-1 MAC被广泛标准化和使用，尤其是在银行业。 该标准（ISO / IEC FDIS 9797-1：2010）的修订版即将发布[93]。
CMAC ：基于CBC-MAC的MAC，该模式作为（VIL）PRF（假设底层的块密码是良好的PRP）可certificate是安全的（达到生日限制）。 基于CBCMAC的scheme基本上是最小的开销。 在某些应用领域中固有的串行性质是一个问题，并且与64位块密码一起使用将需要偶尔的重新密钥。 比ISO 9797-1收集的MAC更清洁。
HMAC ：基于密码散列函数而不是块密码的MAC（尽pipe大多数密码散列函数本身是基于块密码的）。 机制享有强大的可certificate的安全界限，尽pipe不是偏好的假设。 文献中多个密切相关的变体使得了解已知的知识变得复杂。 从来没有人提出过破坏性的攻击。 广泛的标准化和使用。
GMAC ：一种基于随机数的MAC，是GCM的特例。 inheritance了GCM的许多优点和不足之处。 但是对MAC来说，无用的要求是不必要的，在这里它没有什么好处。 实际的攻击，如果标签被截断为≤64位和解密的程度不受监视和削减。 完全失败重用。 无论如何，如果采用GCM，使用是隐含的。 不build议用于单独的标准化。
authenticationencryption（encryption和消息完整性）
CCM ：结合CTR模式encryption和原始CBC-MAC的基于nonce的AEADscheme。 本质上是连续的，在某些情况下限制速度。 certificate安全，有很好的界限，假设底层blockcipher是一个很好的PRP。 毫不留情地施工。 比GCM更容易实施。 可以用作基于随机数的MAC。 广泛的标准化和使用。
GCM ：基于nonce的AEADscheme，结合了CTR模式encryption和基于GF（2128）的通用散列函数。 对于某些实现环境，效率特性很好。 假设最小标签截断的结果是可靠的，安全的。 在大量标记截断的情况下，攻击和可certificate的安全边界很差。 可以用作基于随机数的MAC，然后称为GMAC。 有问题的select允许non-96比特。 build议限制96位的标记和标记至less96位。 广泛的标准化和使用。
你有没有从维基百科上阅读这些信息开始 – 分组密码模式的操作 ？ 然后按照维基百科对NIST的参考链接：对分组密码操作模式的推荐 。
您可能要根据广泛使用的内容进行select。 我有同样的问题，这是我有限的研究成果。
硬件限制
STM32L (low energy ARM cores) from ST Micro support EBC, 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
我知道一个方面：尽pipeCBC通过改变每个块的IV来提供更好的安全性，但不适用于随机访问的encryption内容（如encryption的硬盘）。
因此，使用CBC（和其他顺序模式）顺序stream和ECB随机访问。
