双向非对称加密是如何工作的?

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

反过来让爱丽丝确认是鲍勃发来的。

你现在要做的就是确保鲍伯有爱丽丝的真正公钥,而不是一个中间人注射的。

您所描述的场景确实不能提供真实性。所以爱丽丝和鲍勃都不能确定他们在互相交谈。该方案只提供机密性,因此也不提供机密性。

Bob必须手动向Alice确认他认为是Alice公钥的公钥确实是她的(通过给她打电话并读出LOAD并通过她的声音确认是Alice)。

此问题通常由可信的第三方(例如,证书颁发机构,如verisign)解决,该第三方颁发证书,说明alice确实是此特定公钥的所有者。这是在现代浏览器中解决的方法,也是所有ssl会话(使用您选择的银行)的工作方式。证书颁发机构从您的银行签署证书(声明您的银行确实是证书所包含的公钥的所有者),并且您的浏览器已具有来自证书颁发机构的内置证书(生成可验证的证书链)。

您描述的场景易受所谓的mitm(中间人)攻击,并且不能完全通过公钥加密来解决。

你所说的非常松散,看起来像是在.NET框架中发现的另一个非对称加密算法的实现。

.NET使用两个分支进行非对称加密!!!!

1. RSA**Grand Mac Daddy用于所有非对称ENC。
2. dsa**更多有关使用和创建数字签名来验证作者的信息。

两者都是抽象的

两者在工作方式和开发人员如何实现方面都非常相似,但在下面我读到了两种截然不同的算法。

你说的是选项2。

.NET提供了一个名为dsacryptoserviceprovider的类,该类允许您使用通常称为签名的值标记数据。

根据一本微软官方课程教科书,这里大致介绍了它的工作原理。

数据>>哈希值>>哈希值>>签名 发件人私人密钥>>

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

数据>>哈希ALG>>哈希值解密签名<<<asymm'ALG<<签名 <<<发件人的公开密钥 ?=?

如您所见,bob必须比较生成的散列和解密的签名 以便确认爱丽丝是发送者。dsacrypto'类有4个方法 可以在这里使用,但只有两个是有效的语境。在这个时候,这是bob所能做的,如果他的公钥不是alice的公钥,那么本质上软件应用程序应该阻止bob继续前进,因为bob在试图与alice通信时试图使用伪造的公钥。这是强加的关系,并强调了公钥的重要性。签名允许您验证公钥所有者。

为什么?::

如果bob拥有alice的公钥,那么他可以再次使用相同的算法使用.verifyhash或verifydata方法解密加密的数据。在这种情况下,他们应该直截了当地做些什么。这都是用爱丽丝的公钥完成的。只有alice可以使用signhash和signdata方法,因为它们需要alice的私钥。

如上所示,dsa和rsa cryptoserviceprovider类中已经封装了一定级别的功能。归根结底,你是如何实现它们来验证alice作为发送者的,因为dsa算法允许你通过匹配生成的输出来验证发送者。一定的签名和散列应该匹配,如果它们匹配,那么实际上dsa已经在bob和alice之间为您授予了一定程度的机密性。

因为你假设一个私钥是真正的“私钥”——也就是说,爱丽丝和鲍勃下班时不会把他们的USB钥匙插在他们的机器上。