假设第 1 方和第 2 方各自拥有一个用于 AES 加密数据的密钥。假设密钥是正确随机生成并在它们之间安全传递的。
现在我需要一种方法让第 1 方告诉第 2 方使用哪个存储的密钥。我正在考虑简单地创建密钥的 SHA1 哈希并将其与消息一起发送。我的理由是，第 2 方可以轻松地将该散列与其所有存储密钥的散列进行比较，但被攻击者无法仅从其散列中恢复密钥。
我的要求是防止随意窥探，而不是防止拥有超级计算机的人试图破解此个人信息。理想情况下，我希望第 1 方和第 2 方彼此共享的唯一信息是秘密加密密钥的值。
这个计划是否有任何缺陷，如果有，有更好的方法吗？
显示密钥的散列可能安全也可能不安全，这取决于您使用它做什么。在您的情况下，您有一个密钥K，您为某些哈希函数（例如 SHA-1）显示h(K) ，并且您还为某些加密算法e（例如 AES）和消息M显示e(K,M)。这只是安全的，因为e与h “不同” ，这是一个定义不明确的属性。
例如，假设一个加密算法定义如下：对于消息M和密钥K，使用 SHA-1 对K进行哈希处理，然后使用 AES 的 SHA-1 输出的前 128 位来处理消息M。就加密系统而言，这个相当好；它与“原始 AES”一样好，但它也接受任意长度的密钥。然而，如果你揭示了 SHA-1( K )，那么即使你没有揭示K本身，打破它也变得微不足道。
对于您想要做的事情，您需要在您为密钥索引显示的内容和加密系统之间建立一些隔离层。散列函数不会在其输入和输出之间“一般”提供这样的隔离层，因为可以从输入有效地计算输出（这就是散列函数的意义所在）。另一方面，对于一个“好”的哈希函数，没有已知的方法可以通过只知道另一半来计算输出的一半。否则，对原像抗性的快速攻击将起作用。这会产生以下方案：根据您的密钥K计算 SHA-256( K )。将 256 位输出分成两半 128 位。使用前半部分进行索引（您显示它），后半部分用于实际加密。
为什么不在共享密钥时影响密钥的随机密钥 ID，然后根据该密钥识别密钥，消除所有顾虑......
如果事实证明您的密钥生成过程不是那么随机，这是当今所有关于后门硬件和软件的真正担忧，您的方案将更容易被破坏。随机 id 增加了一个廉价的安全层。除非您在存储空间上受到可笑的限制，否则按照您的方案进行听起来像是不必要的风险。