日本书《图解密码技术》中的数字签名

记得以前写过一篇《》，里面谈到了“数字签名”，在介绍这个名词时，说到了“私钥验证、公钥签名”的概念，曾记得当时为了厘清关系，在网上找了一些资料，看过了浑身感觉挺拧巴的，非常地不舒服，很涩。

最近，抖音给我推荐了一本《图解密码技术》，是日本人结城浩写的、周自恒翻译的；里面有一章节是介绍的数字签名，一气读完，感觉相较于国内的内容，胜在浅显易懂，但深度不如国内。

对一个初学想了解的人来说，入门的直白非常重要，决定着是否能引起兴趣，这方面国内的同行们要引以为诫。当我有了一些这方面的铺垫知识再来看本书的这些内容时，发觉书的例子举得恰当形象，非常地贴切，且循序渐进。

一、公钥密码与数字签名

公钥密码包括一个由公钥和私钥组成的密钥对，其中公钥用于加密，私钥用于解密，如下图，

用公钥进行加密（公钥密码）

数字签名中也同样会使用公钥和私钥组成的密钥对，不过这两个密钥的用法和公钥密码是相反的，即用私钥加密相当于生成签名，而用公钥解密则相当于验证签名，恰好是“反过来用”，如下图，

用私钥进行加密（数字签名）

二、数字签名的方法

直接对消息签名的方法
对消息的散列值签名的方法

1、直接对消息签名

发送者Alice要对消息签名，而接收者Bob要对签名进行验证，方法是：A要事先生成一个包括公钥和私钥的密钥对，而需要验证签名的B则需要得到A的公钥，在此基础上，签名和验证的过程如下图，

A用自己的私钥对消息进行加密；

A将消息和签名发送给B；

B用A的公钥对接收到的签名进行解密；

B将签名解密后得到的消息与A直接发送的消息进行对比；一致则签名验证成功；

2、对消息的散列值签名的方法

上面直接对消息进行加密，非常得耗时，因为公钥密码算法非常慢，如果这时将消息生成一条很短的数据来代替消息本身就好了，这就是单向散列函数。

不必再对整个消息进行加密（对消息签名），而是只要先用单向散列函数求出消息的散列值，然后再将散列值进行加密（对散列值签名）就可以了。

A用单向散列函数计算消息的散列值；

A用自己的私钥对散列值进行加密；

A将消息和签名发送给B；

B用A的公钥对收到的签名进行解密；

B将签名解密后得到的散列值与A直接发送的消息散列值进行对比；

将数字签名中生成的签名和验证的过程整理成一张时间流程图，如下，

三、证书

也称为公钥证书，相当于人的驾照，记录了一系列信息；上面传递时公钥是不有得到保证的，那如何保证公钥的安全呢？这里要用到“可信的第三方”认证机构，如下图

Alice利用认证机构Trent向Bob发送密文的示例

B生成密钥对；

B在认证机构Trent注册自己的公钥；

认证机构Trent用自己的私钥对B的公钥施加数字签名并生成证书；

A得到带有认证机构Trent的数字签名的B的公钥（证书）；

A使用认证机构Trent的公钥验证数字签名，确认B的公钥的合法性；

A用B的公钥加密消息并发送给B；

B用自己的私钥解密密文得到A的消息；

四、公钥基础设施PKI

证书保证了公钥安全，那谁来保护证书的安全，就是公钥基础设施，简称PKI。它是一系列规范和规格的总称，如RSA公司制定的PKCS（Public-Key Cryptography Standards）系列规范也是PKI的一种，而互联网规格RFC(Request for Comments)中也有很多与PKI相关的文档。另外，如X.509这样的规范也是PKI的一种。由于PKI有很多变种，这也是很多人难以理解PKI的原因之一。

1、PKI的组成要素

用户：使用PKI的“人”（或计算机）；
认证机构（CA）：颁发证书的“人”（或计算机）；
仓库（证书目录）：保存证书的数据库；

PKI的组成要素

公钥基础设施PKI总是让人产生一些误解，如“全世界的公钥最终都是由一个根CA来认证的”，其实是不正确的。认证机构只要对公钥进行数字签名就可以了，因此任何人都可以成为认证机构，实际上世界上已经有无数个认证机构了。国家、地方政府、医院、图书馆等公共组织和团体都可以成立认证机构来实现PKI，公司也可以出于业务需要在内部实现PKI。

认证机构的层级