双向非对称加密如何工作？

Question

假设我们有 Alice 和 Bob。

Alice 向 Bob 发送了一条她用 Bob 的公钥加密的消息。 Bob 是唯一可以使用他的私钥解密它的人。但是他怎么能确定消息来自爱丽丝呢？

假设他回复，使用 Alice 的公钥加密他的消息。只有 Alice 可以解密消息。但她怎么能确定它是 Bob 发送的呢？

Alice 是否必须在她的消息中添加某种公共哈希，以便 bob 可以说“这肯定来自 Alice？”

Answer 1

您描述的场景确实不提供真实性。所以 Alice 和 Bob 都不能确定他们正在互相交谈。该方案仅提供机密性，因此也不提供机密性。

Bob 必须手动与 Alice 确认他认为是 Alice 的公钥的公钥确实是她的（通过呼叫她并读出负载并通过她的声音确认是 Alice）。

这个问题通常由受信任的第三方（例如证书颁发机构，如 VeriSign）解决，该第三方颁发证书，说明例如Alice 确实是这个特定公钥的所有者。这是现代浏览器中解决它的方式，也是所有 SSL 会话（使用您选择的银行）的工作方式。证书颁发机构从您的银行签署证书（说明您的银行确实是证书包含的公钥的所有者）并且您的浏览器已经拥有来自证书颁发机构的内置证书（构建可以验证的证书链)。

您描述的场景很容易受到所谓的 MITM（中间人）攻击，并且无法仅通过公钥加密来解决。

Answer 2

Bob 也有 Alice 的公钥，Alice 用她的私钥签署了消息。 Bob 使用 Alice 的公钥来验证签名。

反过来让 Alice 确保消息来自 Bob。

您现在要做的就是确保 Bob 拥有 Alice 的真实公钥，而不是中间人注入的公钥。

Answer 3

您所说的非常非常松散地看起来像是 .Net 框架中的非对称加密算法的另一种实现。

.Net 使用两个分支进行非对称加密！！！

1. RSA ** Grand Mac daddy 用于所有非对称编码目的。
2. DSA ** 更多涉及使用和创建数字签名来验证作者。

都是抽象的

两者在工作方式以及开发人员如何实现它们方面非常相似，但在下面我读到存在两种截然不同的算法。

你说的是选项 2。

.Net 提供了一个名为 DSACryptoServiceProvider 的类，它允许您使用通常称为签名的值标记您的数据。

根据 MS 官方课程教科书，它大致是如何工作的。

数据 >>> 哈希算法 >>> 哈希值 >>>>>>>>> 不对称算法 >>> 签名 发件人的 PVT.KEY >>>

下面展示了 Bob 如何检查 Alice 是否确实是发送者。

数据 >>> 哈希算法 >>> 哈希值 ||解密签名

如您所见，Bob 必须比较生成的 Hash 和 Decrypted Signature 为了验证 Alice 是发送者。 DSACrypto 类有 4 个方法 可以在这里使用，但从上下文来看，只有两个是有效的。在这个时间点，这就是 Bob 所能做的，如果他的公钥不是 alice 的公钥，那么软件应用程序应该阻止 Bob 继续前进，因为当 Bob 试图使用伪造的公钥时试图与爱丽丝交流。这是公钥的强加关系和强调的重要性。签名允许您验证公钥所有者。

为什么？ ::

如果 Bob 拥有 Alice 的公钥，那么他可以使用 .VerifyHash 或 VerifyData 方法再次使用相同的算法来解密加密数据。鉴于这种情况，他们应该直截了当。这一切都是使用 Alice 的公钥完成的。只有 Alice 可以使用 SignHash 和 SignData 方法，因为它们需要 Alice 的私钥。

正如您在上面看到的，特定级别的功能已经封装在 DSA 和 RSA CryptoServiceProvider 类中。它归结为您实现它们以每次验证 Alice 作为发送者的效果如何，因为 DSA 算法允许您通过匹配生成的输出来验证发送者。某个签名和哈希应该匹配，如果它们匹配，那么本质上 DSA 已授予您 Bob 和 Alice 之间一定程度的机密性。

Answer 4

因为您假设私钥确实是“私人的”——即 alice 和 bob 在下班时不会将他们的 USB 密钥插入他们的机器。