我正在创建一个协议，试图在以后“存储”对称密钥会话。我存储了三件事：session_id（公共），symmetric_key（私有）和counter / nonce（私有）。对于每次传输，session_id以明文形式传输并用于查找symmetric_key。对称密钥用于解密数据。数据包含一个散列（sha256），用于验证消息内容。然后，我从内容中提取nonce并检查它是否与存储的nonce匹配。如果它我将存储的nonce增加1.否则，数据包是假的，我扔它。目前，我使用nonce作为symmetric_key的IV。这是一个错误吗？我必须使用完全随机的IV吗？最后，如果我使用随机IV，那么我如何传输多次？我是否需要重新协商新密钥？我正在使用mcrypt库来执行此操作。
要明确，客户端正在发送：[nonce + data + hash（data + nonce）] encrypted + session_key
谢谢！
答案 0 :(得分：1)
我将限制我使用随机IV的答案。 我假设您正在使用需要IV的密码块链接（CBC）模式。
请注意，IV未加密（因为接收方需要解密第一个数据块），因此如果您使用nonce作为IV，而不是说 [nonce + data + hash（数据+ nonce）]加密更准确地说 nonce + [data + hash（data + nonce）]加密，其中+表示连接。
RFC 2451“ESP CBC模式密码算法”说“IV必须随机选择。使用随机生成的IV可防止从包含跨越第一个块的相同数据的数据包生成相同的密文密码算法的块大小。“
除了随机，IV也应该是不可预测的。使用前一个消息的最后一个密文块作为IV的早期实践 - 虽然随机是可预测的 - 是有缺陷的。但是，只有当对手可以安装选择的纯文本攻击时，这个缺陷才会受到关注。也就是说，如果攻击者可以发送所选的纯文本进行加密并且能够看到结果。显然，nonce虽然是唯一的，但是可以预测。
最好使用随机IV。在序列重复之前，您可以播种PRNG并生成IV并保守地重新种子。重新播种时，最好使用密钥交换并更改对称密钥。这将确保对于给定的密钥，您永远不会使用相同的IV两次。
有关所选纯文本攻击的详细信息，请参阅Why is using a Non-Random IV with CBC Mode a vulnerability?
答案 1 :(得分：0)
是的，IV需要仍然是随机的。如果没有，系统是不安全的。这是允许对openssl进行BEAST攻击的错误。您不会多次传输IV，您为每个发送的邮件使用一个新的IV。每次加密新邮件时，选择一个新的IV并发送[IV，ENCRYPT（k，IV，m）]
更重要的是，你的整个协议真的很可疑。您使用的哈希实际上并不能保证某人没有篡改您的数据，因为他们可以轻松地计算哈希值（数据| nonce）。如果您尝试确保不会发生这种情况，请使用带有不同私钥的HMAC。
我真正的建议是，不要编写自己的协议。这些事情真的很难做到。 SSL由很多非常聪明的人组成，即使这样，人们仍然会发现它存在缺陷。值得庆幸的是，这些缺陷很少，而且很复杂。任何一个人写的任何内容都不会出现这种情况。
如果您告诉我您实际尝试使用它的内容，我可以指出一些可能已经执行此操作的现有协议。它可以节省您编写它的时间，实际上是安全的。