在AES中使用相同的IV是否与首先不使用IV相似？

#1 楼

让我们看看我是否可以为您澄清一些事情。

其中一个，IV根本与AES无关。 AES是从128位值转换为128位值的键控可逆转换；这就是它所能做的。现在，如果您只是想将128位值“加密”为128位密文，那么就可以按原样使用AES。

但是，我们通常需要其他方式比起那个来说;我们可能有不完全是128位长的明文；我们可能需要非确定性的加密（因此，如果我们对相同的值进行两次加密，那么这样做就不那么明显了）；我们可能还希望对密文进行完整性检查。

为了允许我们执行这些操作，我们使用一种操作模式；这是使用AES（或其他某种分组密码）执行这些更通用的操作的构造。这些操作模式可能（并非全部）采用IV。

目前，最流行的操作模式是CBC和GCM。他们对IV的要求也非常不同。

因此，在这种情况下，我将回答您的问题：


我应该生成一个每个味精都有不同的IV，因为仅使用一个密钥，如果消息被两次加密，我将获得相同的加密。


是的，如果您使用相同的IV，相同的消息和相同的密钥（对于GCM使用相同的AAD），您将获得相同的密文，但这不是完整的原因。
对于CBC，如果使用相同的IV，则存在两个潜在的问题。一是您将泄漏两个纯文本之间的关系。例如，如果两个纯文本的前16个字节相同，而后16个字节不同，那么这对于攻击者来说是显而易见的。另一个是，如果攻击者可以预测IV（如果您反复使用相同的IV，则可以），并且如果他可以引入自己的纯文本（在某些情况下可能发生），则可以将加密操作用作oracle（并由此推断出用相同密钥加密的低熵纯文本块的值）。对于GCM，如果使用相同的IV，则存在两个不同的潜在问题（两者都远不止这些）严重）;首先，他可以推论两个明文的按位异或（通常足以推论这两个明文）。更糟糕的是，它使攻击者可以推断出内部身份验证值，从而允许他修改密文（并因此而得到的明文）却未被发现。


现在我的问题是使用我所有邮件的相同IV是否完全不使用IV？还是稍微好一点？


好吧，对于这两种模式，您都不能选择“不使用IV”。当您执行CBC或GCM操作时，必须有一个IV（对于GCM，您可以将IV长度设为零；这与“没有IV”并不完全相同）。

您没有要求，但我还是要陈述一般的智慧：


对于CBC模式，IV确实应该是对手无法预测的。现在，您可以每次随机选择它，或者可以使用（例如）使用具有相同密钥的AES加密操作来生成它（攻击者无法预测，因为他没有密钥）。都可以。
对于GCM模式，IV是否可以被对手预测至少无关紧要。至关重要的是您每次都使用不同的密码。如果您可以管理计数器（例如，如果重新启动程序，则将选择一个新密钥），那么显而易见的方法是使用IV = 0作为第一个消息，使用IV = 1作为第二个消息，等等。 >

评论

---

$ \ begingroup $
我要特别感谢您，特别是因为我在这里和安全交换中进行了大量搜索，但不确定是否正确。现在我还有最后一个问题，说我正在使用CBC模式，并且每次都想选择一个不同的IV，我的问题是这是否意味着我必须每次都保存每个IV？我理解这个概念，但发现很难实施。我会将钥匙放在安全的地方，但是每次如何通过IV？ （某些情况下，我试图对数据库中的某些行进行加密，每个客户端将拥有自己的数据库，因此每个客户端都使用不同的密钥）
$ \ endgroup $
–bleh10
18年3月20日在9:48

---

$ \ begingroup $
不，您可以选择随机IV。 CBC模式下AES的IV为128位。选择相同IV的机会非常小，实际上在CBC模式下，密文将用于下一个向量来加密下一个块。为了确保没有冲突并在任何地方生成IV值，但是应保持指定的块加密最大值。对于CBC中的AES，您应该在大约$ 2 ^ {64} $个块之后进行更改-这是一个非常庞大的数字。通常，您应该设计密钥更改。
$ \ endgroup $
–马腾·博德威斯♦
18 Mar 20 '18在9:52

---

$ \ begingroup $
我是否应该认为此实现可安全使用？如果我没记错的话，他们对每条消息都使用具有不同IV的CBC，并且它们随消息一起传递，而不是将其保存在安全的地方。 （对我来说肯定会生成密钥并将其保存在安全的地方，并在需要时使用它）
$ \ endgroup $
–bleh10
18 Mar 20 '18在10:56

---

$ \ begingroup $
@ bleh10：无需“将其保存在安全的地方”；它可以随消息自由传递（实际上，这是将其发送给接收者的最常见方式）
$ \ endgroup $
–雨披
18 Mar 20 '18在11:11

---

$ \ begingroup $
@ bleh10您对实现的指针并不安全！它缺少确保消息完整性的校验和的添加和验证。 HMAC是为此经常使用的机制。始终将校验和添加到加密的字节流中，并始终在尝试解密之前验证校验和。否则，您的加密字节流可能会受到攻击，即，位和字节可能会更改并影响您的解密！
$ \ endgroup $
–Sven
18年3月20日在17:07

---

#2 楼

您不应将其视为“通过AES使用IV”。实际上，除非您是密码学家，否则您应该忘记“ AES”本身是存在的：它是一个伪随机排列族$ \ operatorname {AES} _k \ colon \ {0,1 \} ^ {128} \ to \ {0,1 \} ^ {128} $，这是一个技术行话，对任何应用程序开发人员而言实际上都没有任何意义。

相反，您应该首先确定要执行的操作，例如作为发送消息（任意长度的位字符串）的过程，从爱丽丝到共享密钥的鲍勃。您还应该记住，爱丽丝和鲍勃将发送多少条消息（几？几千？几百万个？），以及它们可能长到几（几千字节，一千兆字节或一兆字节？）。然后，您应该确定对手的能力，例如窃听或可能干扰从爱丽丝到鲍勃的频道。然后，您应该确定所需的安全属性：是否应阻止对手阅读邮件？通过伪造消息？

一旦将这些信息写到应用程序的设计文档中，然后您就可以考虑加密如何为您提供帮助。

通常，您想要的是以确保对手不会阅读或伪造消息，除非您有非常有说服力的理由辩称对手甚至没有机会伪造消息（例如：笔记本电脑上的磁盘加密-如果海关会将您的笔记本电脑带到边境的视线之外，您真的不想再使用该笔记本电脑）或向威权法西斯政权出售有关用户对话的分析。

以挫败能够窃听并干扰Alice和Bob之间的信道，您应该选择经过身份验证的密码或具有关联数据的经过身份验证的加密（AEAD）方案。

在发送者端经过身份验证的密码将获取密钥和消息（任意位字符串）和其他一些参数，然后返回一个密文，而在接收者的末端将获得一个密钥和一个密文以及一些其他参数，要么尖叫，要么伪造！ 1或返回一条消息。

下面是一个经过身份验证的密码示例：AES-GCM。不要将AES-GCM读为“在Galois / Counter操作模式下的块密码伪随机置换族AES”，而是将AES-GCM读为以下合同：


这是您（应用程序开发人员）与AES-GCM之间的合同，是由美国联邦政府和其他次级帝国认可的高级密码学专家铸造的咒语。

您的义务：


必须随机选择一个256位密钥$ k $并将其保密。
对于使用同一密钥$ k $发送的每条消息，必须使用唯一的96位随机数$ n $（有时也称为初始化向量），发送方和接收方就每条消息达成共识。 （您可以在消息旁边发送它，也可以从上下文中推断出它，例如消息序列号。如果Alice和Bob在两个方向上交换消息，则他们不能选择相同的随机数，因此请确保例如Alice使用
使用相同的键$ k $发送的数据总数不得超过$ 2 ^ {60} $个字节。
如果随机选择$ n $，则使用同一密钥$ k $发送的消息不得超过$ 2 ^ {32} $。如果按顺序选择$ n $，则使用相同的密钥$ k $发送的消息不得超过$ 2 ^ {48} $。

在交换中，AES-GCM保证可以自适应地影响Alice和Bob发送的明文以及Alice和Bob打开的密文，


对手甚至无法区分两个等长消息的密文，即使它们是在Alice和Bob之间发送的，因此无法阅读Alice或Bob选择的消息。
对手无法伪造不是Alice或Bob选择的消息。

如果您违反本合同的任何条款，则AES-GCM提供的安全属性将变为无效。


AES-CBC的安全性合同有些不同，部分原因是AES-CBC不提供身份验证，这些词会使您日复一日。 AES-CBC只是一种加密方案，不是经过身份验证的加密方案。 AES-CBC还要求您填充邮件，例如使用PKCS＃7填充（这是称为填充oracle攻击的灾难根源）。


这是您（应用程序开发人员）与AES-CBC之间的合同，AES-CBC是由早期的密码学巫师没有理解他们在过去的原始密码术时代编织的魔术的后果或持久性，而在我们现在所站在的现代基础上就已经建立了。

您的义务：


必须随机选择一个统一的256位密钥$ k $并将其保密。
必须确保您的消息始终为128位的整数倍。
对于使用同一密钥$ k $发送的每条消息，必须选择128位初始化向量，该向量是（a）唯一的，并且（b）事先不可预测的。 （您可以在消息旁边发送它，也可以从上下文中派生它，例如，通过消息序列号的伪随机函数，在发送者和接收者共享的另一个秘密密钥下。）
发送的消息不得超过$ 2使用相同的密钥$ k $总计^ {60} $个字节的数据。
使用相同的密钥$ k $发送的消息不得超过$ 2 ^ {48} $条。

在交换中，AES-CBC保证对抗可能自适应地影响Alice和Bob发送的纯文本的对手。


对手甚至无法区分在Alice和Bob之间发送的两个等长消息的密文，即使他们选择了密文，也无法读取Alice或Bob选择的消息。
就这样。



如果您违反了义务的第（3）（a）条款，则对手可以知道何时两个密文隐藏相同的消息。如果您违反本合同的任何其他条款，则AES-CBC提供的安全属性将无效。


那里还有其他广泛使用的经过身份验证的密码，例如NaCl crypto_secretbox_xsalsa20poly1305或libsodium的变体，比AES-GCM更加安全，但具有较少的帝国认可。 AES还构建了其他咒语，有时被密码学家通称为“操作模式”，他们重视工作安全，而不是大祭司以外的任何人处理密码咒语和用户隐私以及机密和完整性的能力，但这不是论坛中所有咒语的目录-您需要首先编写设计文档，然后才能进一步说明如果不需要认证密码时应该使用哪种密码。

最后，回答您提出的问题：为需要一个操作的操作提供初始化向量是没有道理的。

但是有些API的设计合理，可以最大限度地增加亲爱的读者的困惑，例如通过提供无数个可配置选项的无穷阵列来选择块或流密码，以及密码和密钥的长度，密钥和操作模式以及初始化向量，随机数和身份验证标签以及填充方案以及消息编码和混乱年龄-以此来调味您难以理解的首字母缩写汤。

在这些API中，如果您未能提供一些可选的函数参数来指定IV，或者您没有调用set_iv方法或您拥有什么，那么后台的侏儒可能会默默地为您选择IV。我建议避免使用这些API，或者，如果必须使用它们，则将它们像需要高防护装置并由专家手动握持的核废料一样对待。

#3 楼

IV根本不用于AES。 AES有两个输入：一个128、192或256位密钥和一个128位输入块。它会生成一个128位的输出块。

对于每个密钥，每个输入块在加密过程中都会转换为特定的输出块，并且在解密过程中会颠倒相同的映射。这称为密钥置换，因为密钥定义了将哪些输入块映射到特定的输出块。

AES是一种分组密码，但是不能将分组密码用作通用密码。两次加密相同的块将导致相同的密文-将信息泄漏给对手-您只能加密128位消息。出于这个原因，需要使用AES-像任何块密文一样-操作模式下的功能。与分组密码相比，这种操作模式通常相对简单。所以我们说AES是在一种操作模式下使用的。

大多数情况下，都会使用初始化向量（IV）或一次使用数字（即刻使用）-我将仅使用IV-生成无法与随机区分开的密文的运算。 IV的具体要求几乎完全取决于操作模式。影响IV值的分组密码的唯一因素是块大小，对于AES固定为128位。

IV可以具有以下属性，具体取决于操作模式：


IV的大小可能不同，例如CBC始终要求完整块大小的16字节IV，而GCM默认要求为12字节IV；
IV可能需要从随机到对手难以区分，或者可能仅是唯一的（对于特定密钥）；
选择IV可能会影响可以通过操作方式和分组密码安全加密的消息或块数；

如果IV足够大，则您可能不需要存储有关IV的任何信息：您可以生成一个安全的随机IV并将其与密文一起保存。由于IV足够大，因此生成相同IV的机会也很小，不会成为问题。在特殊情况下，例如12字节GCM IV，这可能会限制应使用相同IV加密的消息数。

如果IV仅需要唯一，则可能重用现有的计数器或标识符。例如，磁盘加密通常将特定的扇区用作IV（或进行调整，请参见注释）。传输协议中的消息通常还包含唯一的序列号。也可以使用分组密码对此类信息进行加密，以生成从随机到对手无法区分的IV。在这种情况下，可能不需要单独发送IV。

通常，可以加密的消息或块的数量是如此之多，以至于这些实际值被忽略了。但是，有时需要考虑一些实际限制。例如，使用诸如三重DES之类的64位分组密码会给您带来一定的限制。 DES几乎不能用于计数器模式加密。 GCM还将对使用特定密钥可以加密多少数据提出更高但可以达到的限制。


注意：


IV不会需要保密。
有些分组密码也接受调整，称为可调整分组密码，这些密码用于专门的结构中，例如安全哈希，Skein哈希函数中的Threefish分组密码就是这样一种可调整的分组密码。 。
有关消息大小和时间的信息可能仍会泄漏；
很多次都忽略了这种操作模式，因为它假定AES将提供所有的安全性。通常这意味着AES以CBC模式运行。
有时IV / nonce的定义不是很好，例如CTR / SIC模式（计数器模式）未指定如何从所需的随机数生成计数器-大多数实现仅要求您生成初始的128位计数器值，并且称之为IV-这意味着如果计数器值之间的距离不够远，您可以将自己开枪射击。
确定性的加密模式不需要您输入IV。一种称为SIV模式或合成IV模式，此处的IV是通过对消息的所有位执行一个运算来计算的-即使单个位不同，SIV模式也会生成唯一的IV，但是仍然必须存在唯一性
ECB模式也不使用IV，但是对于大多数用途来说是不安全的，因为重复的输入块会立即显示。
在AEAD认证的操作模式下，例如GCM， IV不需要单独保护（输入经过身份验证的数据），因为操作模式本身可以解决这一问题；如果在密文上计算出单独的消息身份验证码，则计算中还应包括IV。

#4 楼

特别是，请认真考虑CTR模式下的IV。在CTR模式下，每次启动密码时IV都必须是随机的。如果您在同一密钥下启动两个AES CTR密码，但是两个IV不一定相同，但是随着在整个块中递增而足够接近以至于冲突....那么您就遇到了问题。考虑使用同一密钥使用AES CTR加密两个4GB文件，因为它们只是同一文件的不同版本，但IV仅相差100个块。如果将一个密文滑过100个块并将它们异或在一起，则将同时取消两个中的密钥流；您将得到两个纯文本的异或。