public-key-encryption - 双向非对称加密如何工作？

Question

假设我们有 Alice 和 Bob。

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

假设他回复，使用 Alice 的公钥加密他的消息。只有 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 爸爸用于所有非对称编码的目的。
2. DSA ** 更多地与使用和创建数字签名来验证作者有关。

两者都是抽象的

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

你说的是选项2。

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

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

数据 >>> Hash Alg >>> Hash Value >>>>>>>>> Asymm' Alg >>> Signature Sender's PVT.KEY >>>

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

数据 >>> 哈希算法 >>> 哈希值 || 解密签名 <<< Asymm' Alg <<< Signature <<< Sender's PUB.KEY ? ==？

如您所见，Bob 必须比较生成的哈希和解密签名才能验证 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 密钥插入他们的机器。