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

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

bytesToSend = bytesOfIV + bytesOfCipherText

然后在另一方面，使用了各种巧妙/简单/灵活的方法来分离它们，python中的切片运算符并假设16字节IV特别流行（而且很简单）：

这种方法经受住了时间的考验，这很好，但也非常有限，因为双方（特别是双方的侦听器部分）必须准确地知道如何处理入站字节。事实上，除了切掉IV和使用共享秘密，几乎没有其他操作可以执行。 我正在研究一个设计，其中入站消息有两个部分：一个可以加密，另一个从不加密。显然，敏感信息不会被放入未加密的部分，但因为它是纯文本的，监听器实际上可以在解密之前对内容进行智能处理。示例：消息路由、多个加密密钥的标识符等，当然，这可能包括IV。简化示例：

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

这种方法肯定是“有效的”，并且IV不被认为是秘密的，因此它可以在

中生存，而不被加密。我还喜欢这样一个事实，即人们不必对材料的串联和拆分“聪明”，特别是关于块大小初始化的假设等。如果侦听器需要侦听使用2（或更多）密码加密的材料，这一点尤其正确

问题是：“前缀”方法是否有任何特殊优势。安全性还是仅仅是一种传输两条信息的好方法，而不需要任何额外的奇特数据结构解码？
就安全性而言，不，在密文前面加上IV并没有直接的好处（除了我在下面讨论的HMA的易用性）。您概述的设计与在IV前面加前缀一样安全（提供了正确的实现）

然而，效率肯定是有好处的。考虑在内存中解析和构造JSON对象的资源成本，而不是拆分字节流的成本。后者的速度要快得多。但是，除非您正在处理大量数据，否则您不会注意到这一点

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

请注意，您建议的方法可能更难正确地HMAC您的密文，因为您需要将HMAC应用于IV和密文，因此使用IV前缀密文更容易。
在所有问题上达成一致。JSON风格的设置是富结构的代表性示例；有很多方法可以在不进行解析的情况下表达相同的内容。
{
  neverEncrypted:  {
    cipher: "AES/CBC/PKCS5PADDING",
    IV: "121866AFBBDF2906C0D942C1FA7C4DAB",
    other: [ "hello", 2, 3 ],
    timestamp:  date
  },
  data: (binary cipherText WITHOUT the IV prefix)
}