首页 文章

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

提问于
浏览
389

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

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

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

请参阅“每个标准的评估标准和适用性列表”的含义?

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

7 回答

  • 335

    您是否首先阅读维基百科上的相关信息 - Block cipher modes of operation?然后按照维基百科上的参考链接到NIST: Recommendation for Block Cipher Modes of Operation .

  • 12

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

    硬件限制

    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

  • 275

    我知道一个方面:虽然CBC通过更改每个块的IV来提供更好的安全性,但它不适用于随机访问的加密内容(如加密硬盘) .

    因此,对于顺序流使用CBC(和其他顺序模式),对随机访问使用ECB .

  • -3

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

    • ECB .

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

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

    • CTR .

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

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

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

    • 每次加密时,你应该总是使用唯一的IV,它们应该是random . 如果您不能保证它们是random,请使用OCB,因为它只需要nonce,而不是IV,并且存在明显的差异 . 如果人们可以猜测下一个,nonce不会降低安全性,IV会导致此问题 .
  • 11

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

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

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

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

    This is not a hypothetical scenario: Microsoft had this exact flaw in ASP.NET until a few years ago.

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

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

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

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

    如果由于某种原因您不能使用高级加密库,例如因为您需要以特定方式与现有系统交互,则无法彻底教育自己 . 我建议阅读Cryptography Engineering by Ferguson, Kohno and Schneier . 请尽可能不测试系统的安全性 .

    出于教育目的,比较模式

    仅限加密:

    • Modes that require padding :与示例中一样,填充通常很危险,因为它可以填充oracle攻击 . 最简单的防御是在解密之前验证每条消息 . 见下文 .

    • ECB 独立地加密每个数据块,同一个明文块将产生相同的密文块 . 看一下ECB Wikipedia page上的ECB加密Tux图像,看看为什么这是一个严重的问题 . 我不知道欧洲央行可以接受的任何用例 .

    • CBC 具有IV,因此每次加密消息时都需要随机性,更改消息的一部分需要在更改后重新加密所有内容,一个密文块中的传输错误会完全破坏明文并更改下一个块的解密,解密可以并行化/加密不能,明文在一定程度上具有可塑性 - this can be a problem .

    • Stream cipher modes :这些模式生成可能或可能不依赖于明文的伪随机数据流 . 通常,与流密码类似,生成的伪随机流与明文进行异或运算以生成密文 . 因为您可以根据需要使用随机流的多个位,所以根本不需要填充 . 这种简单性的缺点是加密完全是malleable,这意味着攻击者可以以任何方式改变解密,如明文p1,密文c1和伪随机流r,攻击者可以选择差异等 . 密文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使用随机消息加密是可能的,没有每个消息的随机性,解密是可并行的/加密不是,传输错误完全破坏后面的块,但只影响当前块中的错误位

    • Disk encryption modes :这些模式专门用于加密文件系统抽象下的数据 . 出于效率原因,更改光盘上的某些数据只需要重写最多一个光盘块(512字节或4kib) . 它们超出了这个答案的范围,因为它们的使用场景与其他场景截然不同 . Don't use them for anything except block level disc encryption . 一些成员:XEX,XTS,LRW .

    经过身份验证的加密:

    为了防止填充oracle攻击和密文更改,可以在密文上计算message authentication code(MAC),只有在没有被篡改的情况下才解密它 . 这称为encrypt-then-mac和should be preferred to any other order . 除极少数用例外,真实性如下作为机密性很重要(后者是加密的目的) . 经过身份验证的加密方案(带有关联数据(AEAD))将加密和身份验证的两部分过程合并为一个块密码模式,该模式也会在过程中生成身份验证标记 . 在大多数情况下,这会提高速度 .

    • CCM 是CTR模式和CBC-MAC的简单组合 . 每个块使用两个分组密码加密非常慢 .

    • OCB 更快但受专利限制 . 但是,免费(如在自由中)或非军事软件的专利持有人has granted a free license .

    • GCM 是一种非常快速但可以说是复杂的CTR模式和GHASH组合,一个MAC在Galois字段上有2 ^ 128个元素 . 它在TLS 1.2等重要网络标准中的广泛应用反映在一个special instruction英特尔已经推出加速计算GHASH .

    建议:

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

  • 24
    • 除了欧洲央行之外的任何事情 .

    • 如果使用CTR,则必须为每条消息使用不同的IV,否则最终攻击者可以获取两个密文并获得未加密的明文组合 . 原因是CTR模式实质上将块密码转换为流密码,流密码的第一个规则是永远不要使用相同的密钥IV两次 .

    • 真的没有't much difference in how difficult the modes are to implement. Some modes only require the block cipher to operate in the encrypting direction. However, most block ciphers, including AES, don' t需要更多的代码来实现解密 .

    • 对于所有密码模式,如果您的消息在前几个字节中相同,并且您不希望攻击者知道这一点,则必须为每条消息使用不同的IV .

  • 27

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

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

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

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

    如果您同时需要消息完整性和加密,则可以结合使用两种算法:通常我们会看到CBC与HMAC,但没有理由将自己绑定到CBC . 重要的是要知道encrypt first, then MAC the encrypted content,而不是相反 . 此外,IV需要是MAC计算的一部分 .

    我不知道知识产权问题 .

    现在来自Rogaway教授的好东西:

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

    ECB :一个块码,该模式通过分别加密每个n比特块来加密n比特的倍数的消息 . The security properties are weak ,该方法在块位置和时间上泄漏块的相等性 . 具有相当大的遗留 Value ,并且作为其他方案的构建块具有 Value ,但该模式本身并未实现任何通常所需的安全目标,必须谨慎使用; ECB should not be regarded as a “general-purpose” confidentiality mode .

    CBC :基于IV的加密方案,该模式作为概率加密方案是安全的,假设随机IV,实现与随机比特的不可区分 . Confidentiality is not achieved if the IV is merely a nonce ,也不是在使用的相同密钥下加密的随机数该计划,正如标准错误建议做的那样 . Ciphertexts具有很强的可塑性 . 没有选择的密文攻击(CCA)安全性 . 对于许多填充方法,在存在正确填充的oracle的情况下,机密性将被取消 . 加密从本质上是连续的低效 . 模式的隐私安全属性被广泛使用,导致频繁的误用 . 可以用作CBC-MAC算法的构建块 . I can identify no important advantages over CTR mode.

    CFB :基于IV的加密方案,该模式作为概率加密方案是安全的,假设随机IV,实现与随机比特的不可区分 . Confidentiality is not achieved if the IV is predictable ,也不是由在该方案使用的相同密钥下加密的随机数制作,正如标准错误地建议的那样 . 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在加密或解密时被重用,则完全失去隐私 . 模式的可并行性通常使其在某些设置中比其他机密性模式更快 . 用于经过身份验证的加密方案的重要构建块 . Overall, usually the best and most modern way to achieve privacy-only encryption.

    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位 . 广泛标准化和使用 .

相关问题