如果每个想要解密文件的实体只知道几个可能的密钥，那么最简单的解决方案就是尝试所有这些密钥。这假设您的加密机制包括MAC，无论如何它都应该。MAC 会告诉您数据是否有效，这会捕获数据更改（恶意或非恶意）以及使用错误密钥的简单情况。将 MAC 和加密结合起来充满危险，因此鼓励您使用一种以安全方式结合 MAC 和加密的模式（EAX、GCM ...）。

如果想要解密数据的实体知道很多潜在的加密密钥，那么尝试所有这些密钥可能效率不高，在这种情况下，在文件头中包含密钥标识符可能会有所帮助。密钥的散列还不错，只要散列与用于加密的密钥处理“足够不同”，就不会带来额外的风险。这些是危险的水域——以科学的方式正确地限定这个属性已经够难的了。一种密码学上合理的方法如下：从共享密钥K，计算 SHA-256( K）。这产生 256 位。将其分成两半：前 128 位将是您的“密钥标识符”（可以包含在文件头中），而其他 128 位将是实际用于加密数据的对称密钥。

暴力搜索 128 位 AES 密钥以查找 SHA-1 冲突并不比使用试用解密的暴力密钥搜索更令人担忧。如果您使用 PBKDF2 之类的东西而不是原始哈希，那么您可以使其比试用解密更难。

（事实上​​，这样的碰撞对攻击者没有帮助——如果他们找到具有相同散列的不同密钥，他们将发表一篇关于 SHA-1 抗碰撞性的论文，因为使用 128 位搜索空间它不应该发生，但他们无法解密您的数据。）

如果有人破坏了 SHA-1，那么您确实会遇到问题，因此他们可以从（截断的）哈希中找到密钥，而不是暴力搜索（原像攻击），但在这种情况下，每个使用 SHA-1 进行数字化的人也是如此签名。（在不太可能的情况下，SHA-1 被破坏了，SHA-256 可能也有严重的问题。）

如果您关心攻击者是否能分辨出哪些消息是用相同的密钥加密的，哪些是用不同的密钥加密的，那么您也会遇到问题。例如，如果他们知道某个特定的密钥用于重要消息，并且可以使用该密钥查看更多消息，那么即使他们不知道发生了什么，他们也可能知道正在发生大事（参见http://urbanlegends. about.com/od/government/a/war_and_pizza.htm）。（更改为公钥无济于事。）

在某些情况下，公钥加密不合适，但如果不了解您的用例的更多信息，很难判断这是否是其中之一。

例如，您是将加密信息发送给少数收件人还是大量收件人？如此之多以至于在所有公钥下加密会话密钥是不切实际的？您是否知道将其发送给谁，或者共享密钥的分发由发送者以外的其他人控制（因此您无法知道要使用哪些公钥，您必须相信正确的人知道密钥- 即使那样，为什么不能有共享私钥）？当您可能无法访问原始消息时，您是否希望能够扩大以后可以阅读它的人的集合（通过向其他人透露密钥，当您无法在新的公钥下重新加密时） )? 您是否隐含地假设共享秘密的知识也提供了发送者的真实性 - 如果是这样，对此要非常谨慎。（汤姆·李克的回答对此进行了扩展。另见关于选择 AE 模式的建议。）

我根本不喜欢这种架构。至少，您应该使用具有非常高工作因子的 bcrypt 来生成哈希。这也会为您的哈希添加盐分，从而保护您免受基于彩虹表的攻击。不过，我真的认为你需要阅读更多关于公钥的内容。

如果您的用例需要您事先无法知道要将消息发送给谁，则需要澄清您的用例。公钥加密根本不会阻止中间节点转发（想想公钥加密的电子邮件）。你只需要一个携带密文的封装协议。

特别是，听起来您认为公钥需要与 TLS 一样的主动密钥协商。不是这种情况。您应该查看受 PGP/GPG 保护的电子邮件或 S/MIME 等协议。PKI 看起来确实是您的应用程序的最佳选择。通过利用公共密钥服务器，您可以在别人的一角钱上获得密钥撤销和分发。

密钥共享一直是一个难以破解的难题。这就是使用公钥密码术的原因。

您尝试实现的系统将使用散列算法 (SHA-1) 来检查共享密钥的完整性。假设明天有人能够破解您正在使用的散列算法，那么即使加密，您的系统也会失败您使用的算法足够强大。

在我看来，这不是一个好主意。

PS 即使您使用 SHA-1 是安全的（除非您是大型组织），请切换到 SHA-256。有关详细信息，请参阅此