筆者在前面幾篇文章中，一口氣分別介紹了【對稱加密算法、非對稱加密算法、信息摘要算法】，從中讀者能大致了解到各種算法的應用場景是怎么樣的。這一次，我們將進一步介紹【非對稱加密算法】和【消息摘要算法】的綜合應用：**數字簽名和消息驗簽**。通過本文的閱讀，你可以了解到以下知識：

數字簽名是什么？

為什么數字簽名采用非對稱算法和信息摘要算法？

數字簽名的操作步驟是什么？

消息驗簽的操作步驟是什么？

數字簽名算法的分類

數字簽名的核心應用場景：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的疑問，希望有更多的讀者參與本文的思考和總結。文中的觀點，僅代表筆者之愚見，難免有紕漏之處，希望有心的讀者誠心指正，互相學習，共同進步。感謝感謝。