【问题标题】:Python: use of same IV for encryption and decryption in AESPython:在 AES 中使用相同的 IV 进行加密和解密
【发布时间】:2016-08-03 14:18:27
【问题描述】:

在 AES 中加密数据时,我很难理解 IV(初始化向量)的正确使用。

确切地说,我不确定将随机生成的 IV 存储在哪里:在我的脚本中,数据将被加密,然后保存到文件中,然后程序将终止。在下一个会话期间,必须解密先前保存的数据。如果我对 IV 的理解是正确的,我必须使用与加密相同的 IV 进行解密(但每个加密过程都使用另一个随机 IV)。 因此,我必须将 IV 存储在某处 - 有些人建议将其添加到加密数据之前,但如果我做对了,这在我的情况下将不起作用,因为我需要 IV 以便能够解密它。

这是正确的还是我误解了什么?我想避免在一些未加密的纯文本设置文件或其他东西中保存加密/散列的密钥和 IV(即使是散列本身)。

【问题讨论】:

  • “有些人建议将其添加到加密数据之前,但如果我做对了,那在我的情况下就行不通了” - 我认为错误就在这里。这正是它必须工作的原因。您可能忘记阅读密文前面的 IV 并跳过它进行解密。
  • 我认为这就是重点。我假设 IV 将集成在密文中 - 正如您所写的那样,情况并非如此:它显然是在密文生成之后 预先添加的,然后可以在解密的情况下读取(和拆分) .整个文件保存到的文件类型显然没有改变(例如 txt 或 xml),这使得读取 IV 变得容易。我对在阅读的教程中遇到的 .enc 文件类型感到困惑。我认为在解密之前读取 .enc 文件是不可能的。

标签: python encryption aes initialization-vector


【解决方案1】:

IV 本身不是敏感数据;它只是用来加扰第一个密文块的状态,并且不能从 IV 本身恢复加扰(密钥添加在“秘密”因素中)。

对于“正确”的链接模式,IV 与密文分开(加密和解密都需要初始 IV)并且必须单独存储并单独传递给加密库 API。加密后,您可以随心所欲地存储 IV - 只是不要丢失它;)。

您当然可以“添加”/“添加”到密文,因此您只需要存储一个数据块 - 但您只需在解密之前将其拆分,因为这是 API 所期望的.

执行 IV 的“不正确”方法(例如,如果您的加密库 API 不支持原生 IV,但支持链接)只是在加密之前将单个随机数据块添加到纯文本中。在这种情况下,没有任何 IV 可以单独存储 - 您只需加密整个 IV+消息二进制对 - 然后您只需在解密后删除第一个数据块。您预先添加的“随机数据”具有与真实 IV 相同的约束(不要使用相同的密钥重用相同的随机数据等)。

这两种方法在 API 级别的语义不同,但对实际加密的影响是相同的(无法预测地对实际有效负载的第一块进行扰码)。

就 IV 的使用方式而言 - 有许多可能的方案。请参阅此处有关块链的维基百科文章,以方便的图片显示当 IV 真正单独存储时如何在各种链模式下使用。

https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation

【讨论】:

  • 仅链接的答案不是答案。
  • 谢谢!因此我需要以某种方式解决我的存储问题,你能解释一下我上面描述的“加密悖论”吗?例如,有些人建议将IV保存在加密数据中,在我看来,这使得解码整个事情变得不可能:重新启动脚本后,所需的IV毕竟是加密的,但需要解密......哪个其他位置因此可以推荐保存IV吗?编辑:啊,我错过了@Artjom B. 的评论。我想他明白我的误会了。
  • 扩展了答案,使其不仅仅是一个链接。
  • IV 不应该单独存储,没有必要,它不是私人信息。
  • 那只是应用端的软件设计选择;您可以将其安全地存储在您的应用程序需要的任何位置。最理智的设计肯定只是将它添加到加密流中(因此它可以立即用于解密 API 调用,而无需在磁盘上查找或等到流结束才开始解密),但这不是唯一的方法它。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2018-11-28
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2015-02-14
  • 1970-01-01
  • 2023-04-06
相关资源
最近更新 更多