浅谈非对称算法与数字签名
笔者在前面几篇文章中，一口气分别介绍了【对称加密算法、非对称加密算法、信息摘要算法】，从中读者能大致了解到各种算法的应用场景是怎么样的。这一次，我们将进一步介绍【非对称加密算法】和【消息摘要算法】的综合应用：**数字签名和消息验签**。通过本文的阅读，你可以了解到以下知识：
数字签名是什么？
为什么数字签名采用非对称算法和信息摘要算法？
数字签名的操作步骤是什么？
消息验签的操作步骤是什么？
数字签名算法的分类
数字签名的核心应用场景：https网络通讯
预备知识
在阅读本文之前，笔者假设读者已熟知非对称加密算法和信息摘要算法的基本知识，如对此块知识有缺漏，可自行前往 【算法大杂烩】常见算法的归类和总结——非对称加密算法 以及 【算法大杂烩】常见算法的归类和总结——消息摘要算法 学习相关算法的基础知识。
这里再次补充下，【非对称加密算法】的核心内容：密钥有公钥和私钥之分；公钥对外公开，私钥私有保密；公钥加密对应私钥解密，私钥加密对应公钥解密；加密解密的输入数据长度一般有限制，像RSA算法，输入数据长度应等于模长。【信息摘要算法】的核心内容：不同的数据输入，产生不同的摘要输出，但是摘要的长度是一定的；摘要相同意味着输入数据的原文相同。
数字签名是什么？
签名，一个在日常生活中，很经常听到并使用的名字。在平时，我们经常会签署各式各样的文件，在我国的法律中，亲笔签名在一定程度上是具有法律效力的，表示当事人对签署的文件知悉并且认可，一旦“签名”生成后，它具备了法律意义。又比如，我们在POS机消费后打印的消费单据上签署自己的姓名，则表示持卡人认同这笔消费交易，银行或收单机构拿到这张经消费者签名的单据，就可以完全最终消费款项的清算。在我国，POS机消费时，大部分时候，我们都要输入银行卡密码，打印消费单据后还需要签署自己的姓名；而在国外，由于他们的征信系统较为发达，往往在POS机消费时，是不需要输入银行卡密码的，而消费的唯一凭证确认，就是消费单据上签署的签名。在此种情况下POS机的操作员，有义务确认消费者签署的姓名与卡片背部的参照签名笔迹是否一致；同时，操作员也有权利，当发现消费者签署的姓名笔迹与卡片后背签名笔迹差异较大时，拒绝此卡片消费。通过以上的一些生活例子，我们可以了解到【签名】是一个很重要的玩意，一定程度就代表了本人的认可和无异议。
那么，在数字信息领域，究竟什么是【数字签名】呢？数字签名（又称公钥数字签名、电子签章）是一种类似写在纸上的普通的物理签名，但是使用了公钥加密领域的技术实现，用于鉴别数字信息的方法。一套数字签名通常定义两种互补的运算，一个用于签名，另一个用于验证。数字签名，就是只有信息的发送者才能产生的别人无法伪造的一段数字串，这段数字串同时也是对信息的发送者发送信息真实性的一个有效证明。（摘自： 百度百科 *数字签名*）
从密码学的角度来说，【数字签名】主要解决了两个核心问题：发送的消息是完整的，未被篡改的；接收的消息一定就是对应发送者发送的，别人无法仿制。前者体现的是数据的完整性，后者体现的是数据的不可抵赖性。
为什么数字签名采用非对称算法和信息摘要算法？
从上一小结，我们可以知道【数字签名】的两个核心特点：不可抵赖性和完整性。通过对之前学习的非对称加密算法和信息摘要算法的基础知识一对比，我们可以发现：
非对称加密算法正好解决了不可抵赖性的问题，因为在非对称算法体系中，经私钥加密的数据只有私钥对应的公钥才能解开，别人的公钥是无法解密出原文的，这就是不可抵赖的体现，即任何人都无法冒充发送者。
信息摘要算法恰好解决了数据完整性的问题，因为在信息摘要算法中，不同的数据输入，产生的摘要是不一样的；当摘要数据一样时，我们就可以认为数据原文是一致的，也就认可了数据是完整的，没有被篡改的。
两者一结合，恰好就诞生了【数字签名】这个最佳实践，达到了数据传输中不可修改性的安全要求。
数字签名的操作过程
前面的讲解，我们知道了【数字签名】的特性。在实际的应用过程中，数字签名的应用公式如下所示，其中M表示消息原文，S表示数字签名，P表示非对称算法的私钥运算，D表示信息摘要算法的运算。
P（D（M [with any length]）） = S [with fixed length]
具体来说，发送方产生一个数据签名，需要经过以下几个步骤：
使用【信息摘要算法】，对任意长度的信息原文做摘要运算，得到一段固定长度的摘要数据；
如果该摘要数据的长度，没有达到非对称加密算法做加解密运算的输入长度，通常还需要使用填充标准对摘要数据进行必要的填充，以达到非对称算法的运算条件；常用的填充标准有PKCS1-padding；
使用【非对称加密算法】的私钥对填充后的摘要数据做加密运算，得到一段固定长度的数字签名；
发送方将数字签名拼接在信息原文的尾部，一同发送给接收方，完成数据的单方向传输。
经过以上的步骤后，发送方就成功将信息原文和对应的数字签名，传递给了接收方；剩余的事，就是接收方对数据的验签操作。
消息验签的操作过程
接收方收到发送方发送的数据报文（信息原文+数字签名）后，需要经历以下步骤来完成对报文消息的验签操作：
首先，对数据报文进行分解，提取出信息原文部分和数字签名部分；
与产生数字签名流程一样，使用相同的信息摘要算法对信息原文做摘要运算，得出消息原文的摘要D1；
与产生数字签名流程相反，使用【非对称加密算法】中签名私钥对应的公钥对数字签名部分做解密运算，解密后得到原始发送方发送的经填充后的摘要D2；
与产生数字签名流程相反，使用相同的数据填充标准对摘要D2做去填充操作，得到原始消息的附带的摘要D3；
比较D3和D1；如果两者相等，则表示对数字签名的验签是OK的，消息原文的数据是可信任的；反之，若D3不等于D1，则可以认为消息原文是不可信任的，数字签名中的【完整性】和【不可抵赖性】可能遭到了破坏；我们应该摒弃信息原文。
数字签名算法的分类
数字签名算法，就是使用RSA、MD5、SM2、SHA、SM3等非对称算法和信息摘要算法进行混搭组合。数字签名算法的基本表示格式为：xxxWithYYYEncryption，其中xxx表示信息摘要算法，yyy表示非对称加密算法。常见有的以下几种：
md5WithRSAEncryption：摘要运算采用MD5，非对称算法使用RSA；
sha1WithRSAEncryption：摘要运算采用SHA1，非对称算法使用RSA；
sha256WithRSAEncryption：摘要运算采用SHA256，非对称算法使用RSA；【常用】
sm3WithSM2Encryption：摘要运算采用SM3，非对称算法使用SM2。
数字签名的核心应用场景：https网络通讯
经以上的各小结，我们基本掌握了数字签名的主要内容，这一小节，我们介绍下数字签名的核心应用：https网络通讯。
HTTPS（全称：Hyper Text Transfer Protocol over Secure Socket Layer 或 Hypertext Transfer Protocol Secure，超文本传输安全协议），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。
由它的定义可知，要想实现https，除了应用层需要有http的支持，还需要在传输层支持SSL。SSL正是为了解决网络通讯的安全性问题而诞生的，简单的说，通过SSL的加入，在浏览器和网页服务器之间的数据都是加密的，而不像之前http那样，数据完全在网络上裸奔。目前网络安全问题越来越突出，越来越多的网络信息泄露的案例爆发出来，正是由于这些安全性问题的暴露，SSL的应用得到了越来越多的支持。
限于篇幅原因，本小结不对SSL的具体细节做阐述，仅仅是简要描述数字签名在SSL中的应用方法；后续笔者会写一篇专门的文章来进一步解释SSL通讯的前前后后，敬请关注。
说到数字签名在SSL的应用，它主要是帮助发送方和接收方协商必要的数据，比如网络通讯的加密密钥。我们知道，网络数据是庞大的，而非对称算法的加密速度是远远比对称加密算法慢的，所以在网络通讯的报文不太适合直接使用非对称算法做加密，比较合适的做法的通讯报文还是采用对称加密算法加密，但是对称加密算法使用的对称密钥是发送方和接收方在正式通讯前进行在线协商的；密钥协商的过程使用数字签名的技术，保证协商的密钥是完整的（保证是没被篡改的），并且是不可抵赖的（保证是发送方的）。在密钥协商时，通讯双方分别利用自己的私钥和公钥，结合数字签名技术，完成协商动作。
上面讲消息验签的时候，我们提到消息验签必须要使用签名方的公钥做解密运算，这个公钥一定程度上代表了签名方的身份；但是，我们如何知道我们拿到的公钥，就是我们认为的那个签名方的公钥，而不是网络攻击“中间人”的公钥呢？这就需要CA （Certificate Authority）帮助我们确认这个公钥的合法性。具体的做法是，我们拿到签名方的公钥时，它并不仅仅是一个公钥，而公钥+经CA签名的数字签名，这叫做公钥证书。我们对公钥证书，先用CA的公钥对公钥证书的数字签名进行验签，如果验签成功，则表示我们拿到的公钥是可信任的。那么，CA的公钥，我们又通过谁来保证它是可信任的呢？
这似乎是一个无穷无尽的问题？究竟是怎么回事呢？笔者在这里先卖个关子，有兴趣的读者，可以关注笔者后续有关SSL通讯的详细介绍。
本文通过对非对称算法和信息摘要算法的简要回顾，进而引出【数字签名】的两个核心问题，阐述了数字签名的操作流程以及消息验签的操作过程，读者阅读完本文，应该对数字签名的相关知识有了更多的了解。最后，笔者引出了数字签名在https通讯的核心应用，并抛出有关CA的疑问，希望有更多的读者参与本文的思考和总结。文中的观点，仅代表笔者之愚见，难免有纰漏之处，希望有心的读者诚心指正，互相学习，共同进步。感谢感谢。
