我目前正在从事 voip 项目，并且对 AES-CBC 模式的实施有疑问。我知道对于基于文本消息通信的即时消息，重要的是为每条消息生成一个 IV，以避免在通信过程中第一个块是冗余的情况下可能猜测第一个块。 但是对音频数据做同样的事情有用吗？由于音频数据比明文复杂得多，我想知道为每个音频块生成一个 IV 是否明智（这意味着每秒有很多 IV，超过 40 个），或者这只会减慢一切一无所有？还是只在对话开始时生成一个 IV 就足够了？
提前致谢，
诺尔希安
【问题讨论】：
标签： audio initialization aes vector
您不需要每次都生成新的 IV。 例如，在 SSH 和 TLS 中，只有一个 IV 用于整个数据会话，并且只有在几 GB 数据之后才需要重新生成密钥。
【讨论】：
CBC 要求每个 消息 都有一个新的 IV。但是没有人说你必须一次发送消息。
考虑 SSL/TLS。连接始于一个复杂的过程（“握手”），该过程产生一个共享的“主密钥”，从中派生出对称加密密钥、MAC 密钥和 IV。从那时起直到连接结束（或新的握手），客户端发送到服务器的完整数据，就 CBC 而言，是一个独特的大消息，在逻辑上，它使用了一个独特的 IV。
更详细地说，对于 CBC，每个块（使用 AES 的 16 字节）首先与前一个加密块进行异或运算，然后对其本身进行加密。仅第一个块需要 IV，因为此时没有前一个块。一种看待它的方式是，每个加密块都是随后加密的 IV。当作为 SSL/TLS 对话的一部分，客户端发送一些数据（SSL 中的“记录”）时，它会记住该记录的最后一个加密块，用作下一条记录的 IV。
在你的情况下，我想你有一个音频流要加密。您可以像 SSL/TLS 一样处理它，只需在块之间切分 CBC 流。然而，它有一点复杂：通常，在 VoIP 协议中，一些数据包可能会丢失。如果您收到一块 CBC 加密的数据并且没有前一个块，那么您不知道该块的 IV（即前一个块的最后一个加密块）。然后，您将无法正确解密您收到的块的第一个块（16 个字节）。从这种情况中恢复是否容易取决于您正在加密的数据（特别是，对于音频，您使用哪种压缩算法）。如果这种潜在的丢失是一个问题，那么一种解决方法是在每个块中包含 IV：在 CBC 中，一个块的最后一个加密块（在一个数据包中）作为下一个块中的第一个加密块（在下一个数据包）。
或者，简单地说：您需要每个块一个 IV，但 CBC “自然”生成这些 IV，因为所有 IV（除了第一个）都是您刚刚加密的块。
【讨论】：