1.数字签名

 

1.1 从消息认证码到数字签名

 

消息认证码的局限性

 

还记得我们上篇文章所说的消息认证码吗，我们可以识别消息是否被篡改或者发送者身份是否被伪装，也就是可以校验消息的完整性，还可以对消息进行认证。然而，比如在出具借条的场景中却无法使用消息认证码，因为消息认证码无法防止否认，也就是说不能证明借条是谁签的。

消息认证码之所以无法防止否认，是因为消息认证码需要在发送者Alice和接收者Bob两者之间共享同一个密钥。正是因为密钥是共享的，所以能够使用消息认证码计算出正确MAC值的并不只有发送者Alice，接收者Bob也可以计算出正确的MAC值。由于Alice和Bob双方都能够计算出正确的MAC值，因此对于第三方来说，我们无法证明这条消息的确是由Alice生成的。
 

通过数字签名解决问题
 

下面我们再来假设一种环境，假设发送者Alice和接收者Bob不需要共享一个密钥，也就是说，Alice和Bob各自使用不同的密钥。
 

我们假设Alice使用的密钥是一个只有Alice自己才知道的私钥。当Alice发送消息时，她用私钥生成一个“签名"。相对地，接收者Bob则使用一个和Alice不同的密钥对签名进行验证。使用Bob的密钥无法根据消息生成签名，但是用Bob的密钥却可以对Alice所计算的签名进行验证，也就是说可以知道这个签名是否是通过Alice的密钥计算出来的。如果真有这么一种方法的话，那么不管是识别篡改、伪装还是防止否认就都可以实现了吧。
 

实际上，这种看似很神奇的技术早就已经问世了，这就是数字签名（digital signature）。
 

1.2 签名的生成和验证

 

让我们来稍微整理一下，在数字签名技术中，出现了下面两种行为：

• 生成消息签名的行为

• 验证消息签名的行为
   

生成消息签名这一行为是由消息的发送者Alice来完成的，也称为“对消息签名”。生成签名就是根据消息内容计算数字签名的值，这个行为意味着 “我认可该消息的内容，该内容是我亲自发送的"。
 

验证数字签名这一行为一般是由消息的接收者Bob来完成的，但也可以由需要验证消息的第三方来完成，这里的第三方我们暂且将其命名为验证者Victor。验证签名就是检查该消息的签名是否真的属于Alice，验证的结果可以是成功或者失败，成功就意味着这个签名是属于Alice的，失败则意味着这个签名不是属于Alice的。
 

在数字签名中，生成签名和验证签名这两个行为需要使用各自专用的密钥来完成。
 

Alice使用“签名密钥"来生成消息的签名，而Bob和Victor则使用“验证密钥"来验证消息的签名。数字签名对签名密钥和验证密钥进行了区分，使用验证密钥是无法生成签名的。这一点非常重要。此外，签名密钥只能由签名的人持有，而验证密钥则是任何需要验证签名的人都可以持有。
 

是不是觉得似曾相识的感觉呢？没错，这就是我们讲过的非对称加密。公钥密码和上面讲的数字签名的结构非常相似。在非对称加密中，密钥分为加密密钥和解密密钥，用加密密钥无法进行解密。此外，解密密钥只能由需要解密的人持有，而加密密钥则是任何需要加密的人都可以持有。
 

实际上，数字签名和非对称加密有着非常紧密的联系，简而言之，数字签名就是通过将非对称加密 “反过来用” 而实现的。下面我们来将密钥的使用方式总结成一张表：

 

 1/5    1 2 3 4 5 下一页 尾页

转载：万水千山总是情，打赏一下行不行！感谢您对冰山博客的支持，以及对我们原创作品以及文章的青睐，非常欢迎各位朋友分享到个人站长或者朋友圈，但转载请注明文章出处“来源冰山博客，bsblog123.com”。https://bsblog123.com/Study/Cryptography/2019-03-09/79.html

很赞哦！ ()