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