如何选择AES加密模式(CBC ECB CTR OCB CFB)？

Question

在哪种情况下哪一个更受青睐？

我想看看各种模式的评估crtieria列表,​​也许可以讨论每个标准的适用性.

例如,我认为其中一个标准是加密和解密的"代码大小",这对于微代码嵌入式系统(如802.11网络适配器)非常重要.如果实现CBC所需的代码远小于CTR所需的代码(我不知道这是真的,这只是一个例子),那么我就能理解为什么使用较小代码的模式会更受欢迎.但是,如果我正在编写一个在服务器上运行的应用程序,并且我使用的AES库无论如何都实现了CBC和CTR,那么这个标准就无关紧要了.

请参阅"每个标准的评估标准和适用性列表"的含义？

这与编程无关,但与算法有关.

Answer 1

简介:这个答案部分是对我在__CODE__标签上看到的许多问题的回应,这些问题表明人们部署了完全不安全的代码.在对这些程序员发表讲话时,我写了下面的开头句,打算在他们的应用程序受到攻击之前重新思考他们的密码学方法.如果你在这里学习,那太好了!我们需要更多具有密码学背景知识的程序员.继续询问并添加一个无声的"尚未!" 到我的开场白:

如果您需要提出这个问题,您可能对加密技术知之甚少,无法实现安全系统.

我知道这听起来很苛刻,所以让我说明一下我的观点:想象一下,你正在构建一个Web应用程序,你需要存储一些会话数据.您可以为每个用户分配会话ID,并将会话数据存储在服务器中,并将哈希映射会话ID映射到会话数据.但是你必须在服务器上处理这个讨厌的状态,如果在某些时候你需要多个服务器,事情会变得混乱.因此,您可以将会话数据存储在客户端的cookie中.您当然会加密它,因此用户无法读取和操作数据.那么你应该使用什么模式？来到这里你读到了最顶层的答案(对不起你挑出myforwik).第一个覆盖 - ECB - 不适合你,你想要加密多个块,下一个 - CBC - 听起来不错,你不需要CTR的并行性,你不需要随机访问,所以没有XTS和专利是PITA,所以没有OCB.使用你的加密库你会发现你需要一些填充,因为你只能加密块大小的倍数.您选择PKCS7是因为它是在一些严肃的加密标准中定义的.在阅读某个地方后,如果使用随机IV和安全分组密码,CBC 可证明是安全的,即使您在客户端存储敏感数据,也可以放心.

多年后,您的服务确实已经发展到相当大的规模,IT安全专家会在负责任的披露中与您联系.她告诉你,她可以使用填充oracle攻击来解密所有的cookie ,因为如果填充以某种方式被破坏,你的代码会产生一个错误页面.

这不是一个假设的场景: 几年前微软在ASP.NET中存在这个确切的缺陷.

问题是密码学存在很多陷阱,建立一个对外行人来说安全的系统非常容易,但对于知识渊博的攻击者来说却是微不足道的.

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

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

如果没有可用的高级抽象,请使用高级加密库.一个突出的例子是NaCl和具有许多语言绑定的便携式实现是Sodium.使用这样的库你不必关心加密模式等,但你必须更加小心使用细节而不是更高级别的抽象,比如从不使用两次nonce.

如果由于某种原因您不能使用高级加密库,例如因为您需要以特定方式与现有系统交互,则无法彻底教育自己.我建议阅读Ferguson,Kohno和Schneier的Cryptography Engineering.请不要相信你可以在没有必要背景的情况下建立一个安全的系统.密码学非常微妙,几乎不可能测试系统的安全性.

出于教育目的,比较模式

仅限加密:

• 需要填充的模式:与示例中一样,填充通常很危险,因为它可以填充oracle攻击.最简单的防御是在解密之前验证每条消息.见下文.
  • ECB独立地加密每个数据块,同一个明文块将产生相同的密文块.在ECB维基百科页面上查看ECB加密的Tux图像,看看为什么这是一个严重的问题.我不知道欧洲央行可以接受的任何用例.
  • CBC具有IV并且因此每次加密消息时都需要随机性,改变消息的一部分需要在改变之后重新加密所有内容,一个密文块中的传输错误完全破坏明文并改变下一个块的解密,解密可以并行/加密不能,明文在某种程度上是可塑的 - 这可能是一个问题.
• 流密码模式:这些模式生成可能或可能不依赖于明文的伪随机数据流.通常,与流密码类似,生成的伪随机流与明文进行异或运算以生成密文.因为您可以根据需要使用随机流的多个位,所以根本不需要填充.这种简单性的缺点在于加密是完全可塑的,这意味着攻击者可以以他喜欢的任何方式改变解密,如明文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很简单,它创建一个独立于明文的伪随机流,不同的伪随机流是通过从不同的nonces/IV中计数得到的,这些nonce/IV乘以最大消息长度以防止重叠,使用nonce消息加密是可能没有每个消息随机性,解密和加密完全可并行化,传输错误只影响错误的位,仅此而已
  • OFB还创建一个独立于明文的伪随机流,通过从每个消息的不同随机数或随机IV开始获得不同的伪随机流,加密和解密都不可并行化,因为CTR使用随机消息加密是可能的,没有每条消息随机性,与CTR传输错误一样,只影响错误的位,仅此而已
  • CFB的伪随机流取决于明文,每条消息都需要不同的随机数或随机IV,如CTR和OFB使用随机消息加密是可能的,没有每个消息的随机性,解密是可并行的/加密不是,传输错误完全销毁以下块,但仅影响当前块中的错误位
• 磁盘加密模式:这些模式专门用于加密文件系统抽象下的数据.出于效率原因,更改光盘上的某些数据只需要重写最多一个光盘块(512字节或4kib).它们超出了这个答案的范围,因为它们的使用场景与其他场景截然不同.除块级磁盘加密外,请勿将它们用于任何其他操作.一些成员:XEX,XTS,LRW.

认证加密:

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

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

建议:

考虑到身份验证的重要性,我建议大多数用例使用以下两种分组密码模式(磁盘加密除外):如果数据通过非对称签名进行身份验证,则使用CBC,否则使用GCM.

Answer 2

• 如果使用相同的密钥加密多个数据块,则不应使用ECB.

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

• 如果您想要良好的并行化(即速度)而不是CBC/OFB/CFB,则使用CTR.

• 如果您编码随机可访问数据(如硬盘或RAM),则XTS模式是最常见的.

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

您唯一需要知道的是,除非您只加密1个块,否则不会使用ECB.如果要加密随机访问的数据而不是流,则应使用XTS.

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

Answer 3

一个正式的分析已经由Phil Rogaway在2011年已经完成,在这里.第1.6节给出了我在这里转录的摘要,加上我自己强调的粗体(如果你不耐烦,那么他的建议是使用CTR模式,但我建议你阅读我关于消息完整性与加密的段落).

请注意,其中大多数要求IV是随机的,这意味着不可预测,因此应该使用加密安全性生成.但是,有些只需要一个"nonce",它不要求该属性,而只要求它不被重用.因此,依赖于nonce的设计比不设计的设计更不容易出错(并且相信我,我已经看到许多CBC没有通过正确的IV选择实现的情况).因此,当Rogaway说"当IV是nonce时未达到机密性"时,你会看到我添加了粗体,这意味着如果你选择IV加密安全(不可预测),那么没问题.但如果你不这样做,那么你就失去了良好的安全属性. 切勿在任何这些模式下重复使用IV.

此外,了解消息完整性和加密之间的区别非常重要.加密隐藏数据,但攻击者可能能够修改加密数据,如果您不检查邮件完整性,则软件可能会接受结果.虽然开发人员会说"但修改后的数据将在解密后作为垃圾返回",一位优秀的安全工程师会发现垃圾导致软件不良行为的可能性,然后他会将该分析转化为真正的攻击.我见过许多使用加密的情况,但实际上需要的信息完整性比加密更多.了解您的需求.

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

如果你需要消息完整性和加密,你可以结合两种算法:通常我们看到CBC与HMAC,但没有理由将自己绑定到CBC.重要的是要先加密,然后MAC加密内容,而不是相反.此外,IV需要是MAC计算的一部分.

我不知道知识产权问题.

现在来看看Rogaway教授的好消息:

阻止密码模式,加密但不是消息完整性

ECB:块密码,模式通过分别加密每个n比特块来加密n比特的倍数的消息.安全属性很弱,该方法在块位置和时间上泄漏了块的相等性.具有相当大的遗留价值,并且作为其他方案的构建块具有价值,但该模式本身并未实现任何通常理想的安全目标,必须谨慎使用; 不应将欧洲央行视为"通用"保密模式.

CBC:基于IV的加密方案,该模式作为概率加密方案是安全的,假设随机IV,实现与随机比特的不可区分.如果IV仅仅是一个nonce,并且如果它是在该方案使用的相同密钥下加密的nonce,则不能实现机密性,正如标准错误地建议的那样.Ciphertexts具有很强的可塑性.没有选择的密文攻击(CCA)安全性.对于许多填充方法,在存在正确填充oracle的情况下,机密性将被取消.加密从本质上是连续的低效.模式的隐私安全属性被广泛使用,导致频繁的误用.可以用作CBC-MAC算法的构建块.我认为与CTR模式没有重要优势.

CFB:基于IV的加密方案,该模式作为概率加密方案是安全的,假设随机IV,实现与随机比特的不可区分.如果IV是可预测的,则不能实现机密性,也不是由该方案使用的相同密钥加密的随机数制作,正如标准错误地建议的那样.Ciphertexts是可塑的.没有CCA安全性.加密从本质上是连续的低效.方案取决于参数s,1≤s≤n,通常s = 1或s = 8.对于需要一个阻塞调用仅处理s位而言效率低.该模式实现了一个有趣的"自同步"属性; 在密文中插入或删除任意数量的s位字符只会暂时中断正确的解密.

OFB:基于IV的加密方案,该模式作为概率加密方案是安全的,假设随机IV,实现与随机比特的不可区分.如果IV是随机数,则不能实现机密性,尽管固定的IV序列(例如,计数器)确实可以正常工作.Ciphertexts具有很强的可塑性.没有CCA安全性.加密和解密本身不是串行的.本地加密任何位长度的字符串(不需要填充).我认为与CTR模式没有重要优势.

CTR:基于IV的加密方案,该模式实现了与假定nonce IV的随机位的不可区分性.作为基于安全随机数的方案,该模式还可以用作概率加密方案,具有随机IV.如果nonce在加密或解密时被重用,则完全失去隐私.与其他机密性模式相比,模式的可并行性通常使其在某些设置中更快,速度更快.用于经过身份验证的加密方案的重要构建块.总的来说,通常是实现仅隐私加密的最佳和最现代的方式.

XTS:基于IV的加密方案,该模式通过将可调整的块密码(作为强PRP安全)应用于每个n比特块来工作.对于长度不能被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的MAC集合.

HMAC:基于加密散列函数而不是块密码的MAC(尽管大多数加密散列函数本身都基于块密码).机制享有强大的可证明安全界限,尽管并非优先假设.文献中多个密切相关的变体使获得对已知事物的理解变得复杂.从未提出任何破坏性攻击.广泛标准化和使用.

GMAC:基于随机数的MAC,是GCM的一个特例.继承了GCM的许多优点和缺点.但是对于MAC来说,nonce-requirement是不必要的,在这里它几乎没有什么好处.如果标签被截断为≤64位且解密程度不受监控和缩减,则会产生实际攻击.nonce重用完全失败.如果采用GCM,则无论如何都要隐含使用.不推荐用于单独的标准化.

经过身份验证的加密(加密和消息完整性)

CCM:基于随机数的AEAD方案,结合了CTR模式加密和原始CBC-MAC.在某些情况下,本质上是连续的,限制速度.假设底层封闭是一个很好的PRP,那么可以保证安全,有良好的界限.笨拙的建筑,明显地完成了这项工作.比GCM更容易实现.可以用作基于nonce的MAC.广泛标准化和使用.

GCM:基于随机数的AEAD方案,结合了CTR模式加密和基于GF(2128)的通用散列函数.某些实施环境的良好效率特性.假设标签截断最小,可证明安全性很好.在存在大量标签截断的情况下,攻击和可证明的安全性很差.可以用作基于随机数的MAC,然后称为GMAC.允许96位以外的nonce的可疑选择.建议将nonce限制为96位,将标记限制为至少96位.广泛标准化和使用.

Answer 4

1. 除了欧洲央行之外
2. 如果使用CTR,则必须为每条消息使用不同的IV,否则最终攻击者可以获取两个密文并导出未加密的明文组合.原因是CTR模式实质上将块密码转换为流密码,流密码的第一个规则是永远不要使用相同的Key + IV两次.
3. 模式的实施难度确实没有太大差异.某些模式仅需要分组密码才能在加密方向上运行.但是,大多数分组密码(包括AES)不需要太多代码来实现解密.
4. 对于所有密码模式,如果您的消息在前几个字节中相同,并且您不希望攻击者知道这一点,则对每条消息使用不同的IV非常重要.

Answer 5

您是否首先阅读维基百科上的信息 - 分组密码操作模式？然后按照维基百科上的参考链接进行NIST:分组密码操作模式的建议.

Answer 6

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

硬件限制

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