Bug*_*bug 43 digital-certificate digital-signature
我一直在谷歌的数字签名和数字证书(非对称加密)之间的区别似乎是相同的.我想澄清它们是否相同?非常感谢!!!
kin*_*nak 73
甲数字签名被用于验证的消息.它基本上是消息的加密散列(由发送者的私钥加密).收件人可以通过散列收到的消息并将此值与解密的签名进行比较来检查消息是否被篡改.
要解密签名,需要相应的公钥.一个数字证书是用来绑定公钥人或其他实体.如果没有证书,签名很容易被伪造,因为收件人无法检查公钥是否属于发件人.
证书本身由受信任的第三方签署,如VeriSign等证书颁发机构.
num*_*ati 63
让我扩展阿什利的解释.与加密所有内容一样,假设Alice(发件人)想要向Bob(收件人)发送安全邮件
这里有两个问题需要解决.
这两个问题都可以通过公钥加密来解决.对于(1),Alice用Bob的公钥加密消息.当bob收到消息时,他可以用他的私钥安全地解密它.因此使用Bob的公钥加密并使用Bob的私钥解密(这是公钥加密中的基本内容)
为了解决(2),Alice还发送数字签名和加密消息.这样做如下:
当Bob收到消息+数字签名时,他将:
至于数字证书,请注意Alice依赖于使用Bob的公钥加密原始邮件,Bob依靠Alice的公钥来解密签名.他们两个如何确定彼此的公钥?这就是数字证书的用途.它允许受信任的第三方验证/说"Alice的公钥是xyz".
Ash*_*Ash 21
RSA实验室提供了最清楚的解释:
数字签名: 假设Alice想要向Bob发送签名文档或消息.第一步通常是将哈希函数应用于消息,创建所谓的消息摘要.消息摘要通常比原始消息短得多.事实上,哈希函数的工作是获取任意长度的消息并将其缩小到固定长度.为了创建数字签名,通常签名(加密)消息摘要而不是消息本身.
...
Alice向Bob发送加密的消息摘要和消息,她可以加密也可以不加密.为了让Bob对签名进行身份验证,他必须将与Alice发送给他的消息相同的散列函数应用于Alice,使用Alice的公钥解密加密的消息摘要并比较这两者.如果两者相同,则他已成功验证签名.如果两者不匹配,可能会有一些解释.有人试图模仿Alice,自Alice签署消息或传输过程中发生错误后,消息本身已被更改.
...
数字证书:此外,有人可能假装是爱丽丝,并用他声称是爱丽丝的密钥对签署文件.为了避免诸如此类的情况,存在称为证书的数字文档,其将人与特定公钥相关联.
这些报价来自RSA实验室,网址为http://www.rsa.com/rsalabs/node.asp?id=2182和http://www.rsa.com/rsalabs/node.asp?id=2277
从概念上讲,它们是一种对立面.使用数字证书可以使用公钥加密并使用私钥解密,这样您就可以确保只有拥有私钥的人才能读取您的文本.使用数字签名,您使用私钥加密并使用公钥解密,这样任何人都可以解密,但只有拥有私钥的人才能加密,因此您知道该消息来自具有私钥的人.
@numan 的回答很好地解释了确保机密性、完整性和身份验证的必要过程。但这并没有回答一个真正的问题。
数字签名的目标是提供这些基本服务,
真实性: 发件人已按照其声明对数据进行签名(数据必须使用发件人的私钥加密)。
完整性: 保证数据自签署之日起未发生更改。
不可否认性:接收方可以将数据提供给第三方,第三方可以接受数字签名作为数据交换确实发生的证据。此外,发送方(签名方)不能拒绝对数据进行签名。
它具有确保真实性和完整性的属性,例如,
签名不可伪造:提供签名者而非其他人签署文档的证据。
签名不可否认:这意味着,出于法律目的,签名和文件被视为实物。签名者不能事后声称他们没有签名。
签名未更改:文档签署后,将无法更改。
签名不可重复使用:签名是文档的一部分,不能移动到其他文档。
另一方面,数字证书由某些第三方证书颁发机构 (CA) 颁发,以验证证书持有者的身份。它实际上包含从 CA 自己的私钥派生的证书颁发机构的数字签名。
它还包含与数字证书所有者关联的公钥。
您可能想阅读有关如何构建数字证书的信息。
数字签名解释:
Sender : Encrypt(hash(message), priv_key) = dig_sign
Receiver : Decrypt(dig_sign, pub_key) => hash_of_message == hash(message)
Run Code Online (Sandbox Code Playgroud)
| 归档时间: |
|
| 查看次数: |
69008 次 |
| 最近记录: |