Question

stackoverflow和web上的大多数示例都将CBC初始化向量（IV）作为＆＃34;前缀＆＃34;密文，例如：

bytesToSend = bytesOfIV + bytesOfCipherText

然后在另一方面，使用各种聪明/简单/灵活的方法来分离它们，python中的切片操作符并假设16字节IV特别普遍（并且简单）：

bytesRead = get bytes from source
IV = bytesRead[:16]
cipherText = bytesRead[16:]

这种方法经受住了时间的考验而且很好但是它也非常有限，因为双方（特别是双方的聆听者部分）必须知道完全他们是什么应该使用入站字节。事实上，如果没有切断IV并使用共享秘密，那么几乎没有其他操作可以执行。我正在研究一种设计，其中入站消息有两个部分：一个可以加密，另一个从不加密。显然，敏感信息不会放入未加密的部分，但由于它是纯文本的，因此听众实际上可以通过内容先前进行智能解密。示例：消息路由，多个加密密钥的标识符等。当然，这可能包括IV。简化示例：

{
  neverEncrypted:  {
    cipher: "AES/CBC/PKCS5PADDING",
    IV: "121866AFBBDF2906C0D942C1FA7C4DAB",
    other: [ "hello", 2, 3 ],
    timestamp:  date
  },
  data: (binary cipherText WITHOUT the IV prefix)
}

这种方法肯定会起作用＃34;并且IV不被认为是秘密的，因此它可以存在于neverEncrypted中。我也喜欢这样一个事实：一个人不必得到聪明的＆＃34;关于材料的连接和分裂，尤其是关于块大小初始化等的假设如果监听器需要监听用2（或更多）密码加密的材料，则尤其如此。

问题是：＆＃34;前缀＆＃34;是否有特殊优势？方法安全性还是更好的方法是传输两条信息而不需要任何额外的奇特数据结构解码？

Answer 1

在安全性方面，不，将IV加密到密文没有直接的好处（除了下面我讨论的HMACing的简易性）。您概述的设计与IV前缀一样安全（提供了正确的实现）。

然而，效率肯定有益。考虑在内存中解析和构造JSON对象的资源成本与拆分字节流的成本。后者在天文学上更快。除非你处理的是非常大量的数据，否则你不会注意到这一点。

只要您的加密实现正确，只要两个端点都知道如何处理数据，传输参数的方式就不那么重要了。

请注意，由于您需要将HMAC应用于IV和密文，因此您的建议方法可能更难以正确HMAC密文，因此更容易使用IV前缀密文。

在一条消息中分离AES / CBC IV和密文

1 个答案: