想象一下，一台服务器正在将用户的公钥提供给他们的合作伙伴，以使加密通信成为可能。但是，服务器无权访问私钥..
无论如何 - 想象一下服务器被黑了，它没有发送请求的公钥：
Alice 请求 Bob 的公钥
服务器发送 Eve 的公钥Bob 请求 Alice 的公钥
服务器发送 Eve 的公钥爱丽丝向鲍勃发送消息
服务器解包消息，读取并重新打包 -> 发送给 Bob...Bob 向 Alice 发送消息
服务器解包消息，读取并重新打包 -> 发送给 Alice...
我的问题是 - 如何防止此类滥用？ Alice 如何确定她使用的是 Bob 的公钥，反之亦然？
【问题讨论】：
标签： encryption cryptography rsa public-key
根据你刚才提出的方案，你不能。这里的关键（不是双关语）是，如果用于验证密钥有效性的方法被泄露，你就输了。
SSL 试图通过创建签名链来避免这种情况 - 一些（非常小心地保护并通过其他方法验证）密钥签署另一个密钥，签署另一个密钥，签署爱丽丝的密钥。通过验证链中的每个步骤，您可以（原则上）知道该链是有效的 - 但如果链中任何步骤的私钥被泄露，您就输了。
PGP（又名 GPG）尝试以不同但相似的方式解决问题 - 密钥可以由任意数量的其他密钥签名，形成一个图形（称为 web of trust）。您选择一些您已确认有效的密钥，例如，亲自验证它们，并将它们标记为受信任。然后，任何可通过少于 N 个步骤（和/或来自不同可信根的 M 个不同路径）到达的密钥也被认为是有效的。
如果您真的很偏执，您当然可以亲自将钥匙交给对方。当然，他们必须确定不是伪装成你的人……
也就是说，验证密钥有效性的唯一真正万无一失的方法是自己生成它……除非你的硬件/操作系统/编译器/大脑也受到损害:)
【讨论】：
这里缺少的关键部分是身份验证。 Alice 需要一种方法来知道她真的在使用 Bobs 公钥。一种方法是亲自交换密钥，但这并不总是可行的。
这就是Web of Trust 的用途。如果其他方确定该密钥属于他，则其他方可以签署该用户的公钥。如果有足够多 (3) 个其他联系人（您信任）签署 Bob 的公钥，您可以相对确定这是他的密钥。
【讨论】：
这是公钥加密的主要问题。您没有任何方法可以验证您收到的公钥实际上是您的预期收件人的公钥。 HTTPS/SSL 解决这个问题的方法是使用受信任的证书颁发机构。证书颁发机构用他们的私钥签署相关方的公钥，保证公钥在提供给证书颁发机构后没有被更改。即使这样，也只能保证在您请求时提供给您的密钥与最初提供给证书颁发机构的密钥相同。但是，如果提供这些证书的服务器受到威胁，您仍然会遇到麻烦。如果服务器本身受到威胁，即使让服务器按照上面的建议对密钥进行签名也不是万无一失的。最终，必须维护您的密钥分发服务器的安全性才能使该系统正常工作。
【讨论】：
FAQ for PGP (Pretty Good Privacy) 解释了这个问题。
我还建议阅读 Bruce Schneier 的优秀书籍“Applied Cryptography”，以“友好且易于理解”地讨论这些主题。
【讨论】：