如果 AES 密钥只用一次，使用相同 IV 是否不会影响安全性？按我的理解 IV 作用只是确保相同明文+密钥加密出来的密文每次都不一样

[realpg]

如果你的传输的东西机制上已经防止重放，设计采用加密的作用只是防止中间人识别你传的真实内容，那么不会影响安全性。

以上，我国国有大型银行的某些通讯就是这么设计的，且这个设计方法通过了安全评审。

[iOCZS]

是否需要 iv 是根据算法所采用的 mode 有关，当然 IV 在加密中用来加强密文的安全性，防止攻击者对加密后的数据进行猜测、推测或分析。

[liuidetmks]

还是按照最佳实践来吧，保持 IV 不可预测，与明文无任何信息上关联

IV 不仅仅为了保持密文不一样，OFB 模式下如果相同密钥相同 iv ，人家只要有你一对明文密文，你的后续所有加密也就被破解了


不要自创模式
索尼闹过的一个大乌龙就是随机数不随机，导致密钥被泄露，机器被破解

[Citrus]

@liuidetmks 条件是 AES 密钥只用一次，我理解你说的问题也不存在。

如果能做到严格的一次一密，密钥绝不重复，那没有问题。一次一密是最安全的方式。

[Citrus]

ECB 模式除外。常用的 CBC GCM 没问题。

[cybort]

@Citrus 这是个转移问题的办法，一次一密，那不还要找办法传密钥？加密密钥的密钥是不是重复？

[billccn]

个别 cipher 也许对 IV 的数值敏感，比如不能为特定的 pattern 。

另外如果 IV 固定攻击者就可以开始计算第一个 block 的彩虹表，虽然储存空间需求还是巨大，但如果知道明文的开头也许可以利用 cipher 设计的漏洞减少预计算的量。

[Citrus]

@cybort 这是楼主给的前提条件，我理解不在讨论范围内。

[forvvvv123]

是

“按我的理解 IV 作用只是确保相同明文+密钥加密出来的密文每次都不一样” 这个也是，除了 CBC 模式， 一般 IV 是要求不重复，并不要求不可预测；

[restkhz]

不安全，某些情况请千万不要这么做。你的理解大致是正确的，但是尽可能不要固定 IV 。

赞同 @liuidetmks

AES 归 AES ，但是你的加密模式是什么？楼主没有说。
比如，在上面说的 OFB 和 CTR 模式等等情况下，IV 重用并且密码重用的情况下基本就完蛋了。
比如 CTR ，你只需要知道你的明文去和密文 XOR 一下你就知道密码流了。未来的加密形同虚设。
在 CBC 模式虽然不会被直接破解，但是密文相同，破坏了语义安全。有些场景可以接受。

我简单介绍一下一些概念吧，完美安全和语义安全。
完美安全性就是密文本身不会透露任何明文信息。这个太难了。根据信息论，你需要随机密钥+密钥长度至少有明文那么长才能做到。这个时候你的熵就高的足以用来混淆任何一个明文 bit 。
所以楼上 @Citrus 其实说的不完全正确。因为你密码长度只要小了就是不行。不是说会暴力破解，单纯就是熵不够。
你说的严格一次一密，你是指每个 block 都一密码还是完全参照已有的 AES 模式呢？如果你能做到前者，恭喜你，但是直接换成 XOR 玩 OTP 可能更好。做到后者，比如 CBC 模式中，密码随机 IV 固定依旧做不到语义安全。
做到这个太难了。密钥生成，传输，都是问题。

于是人们退而求其次，密文可能会暴露明文信息，但无法被有效利用。这个就是语义安全了。
保存和更新密码的成本太高了。默认密码就会重用。设计的时候也是这么设计的。

这个时候引入 IV 你的确可以理解为增加信息熵，增加密文随机性。某种意义上来说 IV 解决了密码重用的问题(密码学角度的问题)

[restkhz]

不好意思，没仔细审题，一次一密码，给上上下下都道个歉，想删除的时候不小心发出来了。尤其是给 @Citrus 道个歉，我没仔细审题。
你提醒我了，你说的对。送一个感谢表示诚意。

感觉怪怪的，想了一会，没想出有啥问题。

[Citrus]

@restkhz 😆太客气了。
其实不用感觉怪怪的。IV 之类的机制，引入的主要目的就是在 密钥重用 的前提下，增加随机性，从而保证相同明文不会加密为相同密文，从而安全的在 密钥不变 的情况下通信。
所以，保证严格的一次一密，那这个大前提不存在了，自然问题就不存在了。密钥本身已经提供了足够的随机性，不再需要额外的机制保证随机性。
当然，目前并没有很好的方式去做这个一次一密，所以理论可行，但是不现实。