您所讨论的内容非常非常松散,看起来像.Net框架中的非对称加密算法的另一种实现。
.Net采用两个分支进行非对称加密!
的 两者都是抽象的 强>
两者关于它们如何工作以及开发人员如何实现它们彼此非常相似,但在下面我已经读过两种截然不同的算法。
你说的是选项2。
.Net提供了一个名为DSACryptoServiceProvider的类,它允许您使用通常称为签名的值标记数据。
根据MS官方课程教科书大致说明它的工作原理。
数据>>> Hash Alg>>>哈希值>>>>>>>>>> Asymm'Alg>>>>签名 发件人的PVT.KEY>>>
下面显示了Bob如何检查Alice是否确实是发件人。
数据>>> Hash Alg>>>哈希值||解密签名<<< Asymm'Alg<<<签名 <<<发件人的PUB.KEY ? ==?
如您所见,Bob必须比较生成的Hash和Decrypted Signature 为了验证Alice是发件人。 DSACrypto'类有4种方法 可以在这里使用,但只有两个在上下文中有效。在这个时间点,这是鲍勃可以做的全部,如果他的公钥不是爱丽丝的公钥,那么基本上软件应用程序应该阻止鲍勃死在他的轨道上继续进行,因为鲍勃试图使用伪造的公钥时试图与爱丽丝沟通。这是强加的关系,并强调了公钥的重要性。签名允许您验证公钥所有者。
这是为什么? ::
如果Bob拥有Alice的公钥,那么他可以再次使用相同的算法来使用.VerifyHash或VerifyData方法解密加密数据。应该直截了当地给出了这样的背景。这都是使用Alice的公钥完成的。只有Alice可以使用SignHash和SignData方法,因为它们需要Alice的私钥。
如您所见,DSA和RSA CryptoServiceProvider类中已封装了一定级别的功能。它归结为您实现它们以及每次验证Alice作为发送方的程度,因为DSA算法允许您通过匹配生成的输出来验证发送方。某个签名和哈希应该匹配,如果他们这样做,那么本质上DSA已经授予您Bob和Alice之间的一定程度的机密性。
因为你假设私钥真的是“私有的” - 即alice和bob在离开工作时不要将他们的USB密钥插入他们的机器。
您描述的场景确实无法提供真实性。所以爱丽丝和鲍勃都不能确定他们是在互相交谈。该方案仅提供机密性,因此也不保密。
Bob必须与Alice手动确认他认为公钥是Alice的公钥确实是她的(通过打电话给她并读出它并通过她的声音确认它是Alice)。
此问题通常通过可信第三方(例如证书颁发机构,如VeriSign)解决,该第三方颁发证明该问题的证书。 Alice确实是这个特定公钥的所有者。这是在现代浏览器中解决的方式,这是所有SSL会话(与您选择的银行)一起工作的方式。证书颁发机构从您的银行签署证书(说明您的银行确实是证书所包含的公钥的所有者),并且您的浏览器具有来自证书颁发机构的已内置证书(构建可以验证的证书链) )。
您描述的场景容易受到所谓的MITM(中间人)攻击,并且不能完全用公钥加密解决。