我目前正在开展一个voip项目，并对AES-CBC模式的实施有疑问。我知道，对于基于文本消息通信的即时消息传递，重要的是为每条消息生成一个IV，以避免在通信期间如果这个消息冗余时可能猜到第一个块。 但对音频数据做同样的事情是否有用？由于音频数据比明文复杂得多，我想知道为每个音频块生成一个IV是否明智（这意味着每秒有很多IV，超过40个），或者这只会减慢一切一无所获？或者只是在对话开始时生成的一个IV就足够了？
提前致谢，
Nolhian
答案 0 :(得分：1)
您不需要每次都生成新的IV。 例如，在SSH和TLS中，只有一个IV用于整个数据会话，只有在几克数据之后才需要重新加密。
答案 1 :(得分：1)
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（除了第一个）都是刚刚加密的块。