加密某些数据与签署某些数据(使用RSA)之间的区别是什么?

它只是颠倒了公共-私有密钥的角色吗?

For example, I want to use my private key to generate messages so only I can possibly be the sender. I want my public key to be used to read the messages and I do not care who reads them. I want to be able to encrypt certain information and use it as a product-key for my software. I only care that I am the only one who can generate these. I would like to include my public key in my software to decrypt/read the signature of the key. I do not care who can read the data in the key, I only care that I am the only verifiable one who can generate them.

签名在这种情况下有用吗?


当前回答

签名是用您的私钥生成一个“散列”,可以用您的公钥进行验证。文本是明文发送的。

加密使用接收方的公钥来加密数据;解码是用他们的私钥完成的。

因此,密钥的使用不会反转(否则您的私钥将不再是私有的!)。

其他回答

签名是用您的私钥生成一个“散列”,可以用您的公钥进行验证。文本是明文发送的。

加密使用接收方的公钥来加密数据;解码是用他们的私钥完成的。

因此,密钥的使用不会反转(否则您的私钥将不再是私有的!)。

加密某些数据与签署某些数据(使用RSA)之间的区别是什么?

加密保留了消息(“一些数据”)的机密性,而签名提供了不可抵免性:即只有签署它的实体才能签署它。还有功能上的差异;继续读下去。

它只是颠倒了公共-私有密钥的角色吗?

绝对不是。使用相同的私钥进行签名和解密(或者同样地,使用相同的公钥进行验证和加密)是不允许的,因为您不应该混合使用这些目的。这不是一个数学问题(RSA应该仍然是安全的),而是一个密钥管理的问题,例如,签名密钥应该有更短的存活时间,并在使用前包含更多的保护。

对于相同的消息,应该使用发送方的私钥进行签名,使用接收方的可信公钥进行加密。通常使用签名后加密,否则对手可以用自己的签名替换签名。同样,您应该使用接收方的私钥进行解密,使用发送方的可信公钥进行验证。

此外,您应该理解签名生成不使用“私钥加密”。虽然所有的RSA操作都是基于模取幂,填充方案是完全不同的签名生成。此外,在RSA的所有实际应用中,公钥与RSA私钥具有完全不同的属性。

例如,我想使用我的私钥来生成消息,这样只有我可能是发送者。

这就是不可抵赖性,可以通过签名来实现。

我希望我的公钥被用于阅读消息,我不关心谁阅读它们。

公钥应该被认为是所有人都知道的。如果您希望每个人都能阅读消息,那么您只需不加密它们。

签名通常不会影响消息的内容。消息被认为是独立于签名的。这种签名在官方上被称为“带附录的签名”,其中附录就是信息。这是一个有点奇怪的名字,因为信息被认为比上面的签名更重要,但是是的。只有少数签名提供(部分)消息恢复;它们不再经常使用,通常被认为已弃用。

请注意,诸如CMS之类的签名协议可以部署包含消息和签名的容器格式。在这种情况下,您首先需要从容器中获取尚未加密的消息,就像从普通的.zip归档文件中解压缩文件一样。因此,消息可能从视图中隐藏,在这种情况下不能直接使用。

我希望能够加密某些信息,并将其用作我的软件的产品密钥。我只在乎我是唯一能产生这些的人。

加密用于实现机密性。在过去,RSA签名生成通常被认为是“用私钥加密”。然而,如上所述,操作是完全不同的,后来的标准拼命地尝试将加密和签名生成分开。

我想在我的软件中包含我的公钥,以解密/读取密钥的签名。我不关心谁可以读取密钥中的数据,我只关心我是唯一可以生成它们的可验证的人。

是的,这被称为在公钥中建立信任。但是,保护程序代码与保护消息是完全不同的。您可以执行代码签名,但随后需要一些东西来检查代码之外的签名。有一些操作系统提供这种功能。

比如微软的Authenticode。像iStore和Android应用程序商店这样的应用程序商店可能使用也可能不使用代码签名,但它们提供了一些保证,确保您的应用程序不是克隆的,或者至少不是在商店内克隆的。密码学并非总能解决问题。

让你的代码不被克隆/修改要困难得多,如果你这样做,你就会陷入数字版权管理的领域。

签名在这种情况下有用吗?

是的,当然。如果对公钥有信任,它当然可以帮助确保消息仅由您签名。它是否有助于验证应用程序代码/集成公钥,这完全取决于您希望在其中运行代码的环境。

加密时,你用他们的公钥写消息,他们用他们的私钥读取消息。

在签名时,你使用你的私钥来写消息的签名,他们使用你的公钥来检查它是否真的是你的。

我想使用我的私钥来生成消息,这样只有我可能是发送者。 我希望我的公钥被用于阅读消息,我不关心谁阅读它们

这是签名,它是用你的私钥完成的。

我希望能够加密某些信息,并将其用作我的软件的产品密钥。 我只在乎我是唯一能产生这些的人。

如果你只需要自己知道它,你不需要弄乱钥匙来做到这一点。您可能只是生成随机数据并将其保存在数据库中。

但如果你想让人们知道密钥确实是你的,你需要生成随机数据,保存在数据库中,并用你的密钥签名。

我想在我的软件中包含我的公钥,以解密/读取密钥的签名。

您可能需要从Verisign或Thawte等商业提供商处购买公钥证书,以便人们可以检查是否有人伪造了您的软件,并将您的公钥替换为他们的。

签名表明您确实是已签名对象的来源或担保。不过,每个人都可以读取对象。

加密意味着只有拥有相应私钥的人才能读取它,但如果没有签名,就不能保证您是加密对象的幕后黑手。

在RSA加密中,当你生成一个密钥对时,选择哪一个作为公钥,哪一个作为私钥是完全随意的。如果你用一个加密,你可以用另一个解密——它是双向工作的。

因此,如何使用接收方的公钥加密消息,以便接收方可以使用他们的私钥解密消息是相当简单的。

签名是签名者拥有与某个公钥匹配的私钥的证明。要做到这一点,使用发送方的私钥加密消息就足够了,并将加密版本与明文版本一起包含。要验证发件人,请解密加密版本,并检查它是否与明文相同。

当然,这意味着你的信息不是秘密。任何人都可以解密它,因为公钥是众所周知的。但是当他们这样做的时候,他们已经证明了密文的创造者拥有相应的私钥。

然而,这意味着将传输的大小增加一倍——明文和密文一起传输(假设您希望那些对验证签名不感兴趣的人阅读消息)。因此,签名通常是通过创建明文的散列来创建的。重要的是不能创建假哈希,因此使用SHA-2等加密哈希算法。

So:

要生成签名,请从明文中生成哈希,用您的私钥加密它,并将其与明文一起包含。 要验证签名,请对明文进行哈希,用发送方的公钥解密签名,检查两个哈希是否相同。