數字摘要加密過程

① 詳解https是如何確保安全的

（多文字預警）

HTTPS（全稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全為目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容就需要SSL

下面就是https的整個架構，現在的https基本都使用TLS了，因為更加安全，所以下圖中的SSL應該換為SSL/TLS。

下面就上圖中的知識點進行一個大概的介紹。

對稱加密(也叫私鑰加密)指加密和解密使用相同密鑰的加密演算法。有時又叫傳統密碼演算法，就是加密密鑰能夠從解密密鑰中推算出來，同時解密密鑰也可以從加密密鑰中推算出來。而在大多數的對稱演算法中，加密密鑰和解密密鑰是相同的，所以也稱這種加密演算法為秘密密鑰演算法或單密鑰演算法。
常見的對稱加密有：DES（Data Encryption Standard）、AES（Advanced Encryption Standard）、RC4、IDEA

與對稱加密演算法不同，非對稱加密演算法需要兩個密鑰：公開密鑰（publickey）和私有密鑰（privatekey）；並且加密密鑰和解密密鑰是成對出現的。非對稱加密演算法在加密和解密過程使用了不同的密鑰，非對稱加密也稱為公鑰加密，在密鑰對中，其中一個密鑰是對外公開的，所有人都可以獲取到，稱為公鑰，其中一個密鑰是不公開的稱為私鑰。

數字摘要是採用單項Hash函數將需要加密的明文「摘要」成一串固定長度（128位）的密文，這一串密文又稱為數字指紋，它有固定的長度，而且不同的明文摘要成密文，其結果總是不同的，而同樣的明文其摘要必定一致。「數字摘要「是https能確保數據完整性和防篡改的根本原因。

數字簽名技術就是對「非對稱密鑰加解密」和「數字摘要「兩項技術的應用，它將摘要信息用發送者的私鑰加密，與原文一起傳送給接收者。接收者只有用發送者的公鑰才能解密被加密的摘要信息，然後用HASH函數對收到的原文產生一個摘要信息，與解密的摘要信息對比。如果相同，則說明收到的信息是完整的，在傳輸過程中沒有被修改，否則說明信息被修改過，因此數字簽名能夠驗證信息的完整性。
數字簽名的過程如下：
明文 --> hash運算 --> 摘要 --> 私鑰加密 --> 數字簽名

數字簽名有兩種功效：
一、能確定消息確實是由發送方簽名並發出來的，因為別人假冒不了發送方的簽名。
二、數字簽名能確定消息的完整性。

對於請求方來說，它怎麼能確定它所得到的公鑰一定是從目標主機那裡發布的，而且沒有被篡改過呢？亦或者請求的目標主機本本身就從事竊取用戶信息的不正當行為呢？這時候，我們需要有一個權威的值得信賴的第三方機構(一般是由政府審核並授權的機構)來統一對外發放主機機構的公鑰，只要請求方這種機構獲取公鑰，就避免了上述問題的發生。

用戶首先產生自己的密鑰對，並將公共密鑰及部分個人身份信息傳送給認證中心。認證中心在核實身份後，將執行一些必要的步驟，以確信請求確實由用戶發送而來，然後，認證中心將發給用戶一個數字證書，該證書內包含用戶的個人信息和他的公鑰信息，同時還附有認證中心的簽名信息(根證書私鑰簽名)。用戶就可以使用自己的數字證書進行相關的各種活動。數字證書由獨立的證書發行機構發布，數字證書各不相同，每種證書可提供不同級別的可信度。

瀏覽器默認都會內置CA根證書，其中根證書包含了CA的公鑰

1、2點是對偽造證書進行的。3是對於篡改後的證書驗證，4是對於過期失效的驗證。

SSL為Netscape所研發，用以保障在Internet上數據傳輸之安全，利用數據加密(Encryption)技術，可確保數據在網路上之傳輸過程中不會被截取，當前為3。0版本。

SSL協議可分為兩層： SSL記錄協議（SSL Record Protocol）：它建立在可靠的傳輸協議（如TCP）之上，為高層協議提供數據封裝、壓縮、加密等基本功能的支持。 SSL握手協議（SSL Handshake Protocol）：它建立在SSL記錄協議之上，用於在實際的數據傳輸開始前，通訊雙方進行身份認證、協商加密演算法、交換加密密鑰等。

用於兩個應用程序之間提供保密性和數據完整性。
TLS 1.0是IETF（Internet Engineering Task Force，Internet工程任務組）制定的一種新的協議，它建立在SSL 3.0協議規范之上，是SSL 3.0的後續版本，可以理解為SSL 3.1，它是寫入了 RFC 的。該協議由兩層組成： TLS 記錄協議（TLS Record）和 TLS 握手協議（TLS Handshake）。較低的層為 TLS 記錄協議，位於某個可靠的傳輸協議（例如 TCP）上面。

SSL與TLS握手整個過程如下圖所示，下面會詳細介紹每一步的具體內容：

由於客戶端(如瀏覽器)對一些加解密演算法的支持程度不一樣，但是在TLS協議傳輸過程中必須使用同一套加解密演算法才能保證數據能夠正常的加解密。在TLS握手階段，客戶端首先要告知服務端，自己支持哪些加密演算法，所以客戶端需要將本地支持的加密套件(Cipher Suite)的列表傳送給服務端。除此之外，客戶端還要產生一個隨機數，這個隨機數一方面需要在客戶端保存，另一方面需要傳送給服務端，客戶端的隨機數需要跟服務端產生的隨機數結合起來產生後面要講到的 Master Secret 。

客戶端需要提供如下信息：

服務端在接收到客戶端的Client Hello之後，服務端需要確定加密協議的版本，以及加密的演算法，然後也生成一個隨機數，以及將自己的證書發送給客戶端一並發送給客戶端。這里的隨機數是整個過程的第二個隨機數

服務端需要提供的信息：

客戶端首先會對伺服器下發的證書進行驗證，驗證通過之後，則會繼續下面的操作，客戶端再次產生一個隨機數（第三個隨機數），然後使用伺服器證書中的公鑰進行加密，以及放一個ChangeCipherSpec消息即編碼改變的消息，還有整個前面所有消息的hash值，進行伺服器驗證，然後用新秘鑰加密一段數據一並發送到伺服器，確保正式通信前無誤。
客戶端使用前面的兩個隨機數以及剛剛新生成的新隨機數，使用與伺服器確定的加密演算法，生成一個Session Secret。

服務端在接收到客戶端傳過來的第三個隨機數的 加密數據之後，使用私鑰對這段加密數據進行解密，並對數據進行驗證，也會使用跟客戶端同樣的方式生成秘鑰，一切准備好之後，也會給客戶端發送一個 ChangeCipherSpec，告知客戶端已經切換到協商過的加密套件狀態，准備使用加密套件和 Session Secret加密數據了。之後，服務端也會使用 Session Secret 加密一段 Finish 消息發送給客戶端，以驗證之前通過握手建立起來的加解密通道是否成功。

後續客戶端與伺服器間通信
確定秘鑰之後，伺服器與客戶端之間就會通過商定的秘鑰加密消息了，進行通訊了。整個握手過程也就基本完成了。

對於非常重要的保密數據，服務端還需要對客戶端進行驗證，以保證數據傳送給了安全的合法的客戶端。服務端可以向客戶端發出 Cerficate Request 消息，要求客戶端發送證書對客戶端的合法性進行驗證。比如，金融機構往往只允許認證客戶連入自己的網路，就會向正式客戶提供USB密鑰，裡面就包含了一張客戶端證書。

PreMaster secret前兩個位元組是TLS的版本號，這是一個比較重要的用來核對握手數據的版本號，因為在Client Hello階段，客戶端會發送一份加密套件列表和當前支持的SSL/TLS的版本號給服務端，而且是使用明文傳送的，如果握手的數據包被破解之後，攻擊者很有可能串改數據包，選擇一個安全性較低的加密套件和版本給服務端，從而對數據進行破解。所以，服務端需要對密文中解密出來對的PreMaster版本號跟之前Client Hello階段的版本號進行對比，如果版本號變低，則說明被串改，則立即停止發送任何消息。

有兩種方法可以恢復原來的session：一種叫做session ID，另一種叫做session ticket。

session ID
session ID的思想很簡單，就是每一次對話都有一個編號（session ID）。如果對話中斷，下次重連的時候，只要客戶端給出這個編號，且伺服器有這個編號的記錄，雙方就可以重新使用已有的」對話密鑰」，而不必重新生成一把。

session ticket
客戶端發送一個伺服器在上一次對話中發送過來的session ticket。這個session ticket是加密的，只有伺服器才能解密，其中包括本次對話的主要信息，比如對話密鑰和加密方法。當伺服器收到session ticket以後，解密後就不必重新生成對話密鑰了。

總結
https實際就是在TCP層與http層之間加入了SSL/TLS來為上層的安全保駕護航，主要用到對稱加密、非對稱加密、證書，等技術進行客戶端與伺服器的數據加密傳輸，最終達到保證整個通信的安全性。

收錄自| 原文地址

② 數字摘要的基本原理

數字摘要的基本原理:

發送端把原信息用HASH函數加密成摘要,然後把數字摘要和原信息一起發送到接收端,接收端也用HASH函數把原消息加密為摘要,看兩個摘要是否相同,若相同,則表明信息的完整.否則不完整.
它用來保證信息的完整性

數字信封的基本原理:
發送端使用對稱密鑰來加密數據,然後將此對稱密鑰用接收者的公鑰加密,稱為加密數據的」數字信封」,將其和加密數據一起發送給接受者,接受者先用自己的私鑰解密數字信封,得到對稱密鑰,然後使用對稱密鑰解密數據.
它用來保證信息的保密性.

數字簽名的基本原理:
發送方首先用HASH函數對原文件生成數字摘要,用自己的私鑰對這個數字摘要進行加密來形成發送方的電子簽名,附在文件後.然後用一個對稱密鑰對帶有電子簽名的原文件加密,再用接收方的公鑰給對稱密鑰加密,然後把加密後的密鑰文件傳送給接受方.接收方用自己的私鑰對密鑰密文解密,得到對稱密鑰,用對稱密鑰對原文件密文進行解密,同時得到原文件的電子簽名,再用發送方的公鑰對電子簽名解密,得到電子簽名的HASH 值,然後用HASH函數對得到的原文件重新計算HASH值,並與解密電子簽名得到的HASH值進行對比.
它用來保證信息的不可抵賴性和完整性.

③ 數字摘要的基本原理

（1） 被發送文件用SHA編碼加密產生128bit的數字摘要（見上節）。（2） 發送方用自己的私用密鑰對摘要再加密，這就形成了數字簽名。
（3） 將原文和加密的摘要同時傳給對方。
（4） 對方用發送方的公共密鑰對摘要解密，同時對收到的文件用SHA編碼加密產生又一摘要。
（5） 將解密後的摘要和收到的文件在接收方重新加密產生的摘要相互對比。如兩者一致，則說明傳送過程中信息沒有被破壞或篡改過。否則不然。

④ 簡述數字簽名的原理

數字簽名就是附加在數據單元上的一些數據,或是對數據單元所作的密碼變換。這種數據或變換允許數據單元的接收者用以確認數據單元的來源和數據單元的完整性並保護數據,防止被人(例如接收者)進行偽造。

它是對電子形式的消息進行簽名的一種方法,一個簽名消息能在一個通信網路中傳輸。基於公鑰密碼體制和私鑰密碼體制都可以獲得數字簽名,主要是基於公鑰密碼體制的數字簽名。包括普通數字簽名和特殊數字簽名。

(4)數字摘要加密過程擴展閱讀：

數字簽名有兩種功效：一是能確定消息確實是由發送方簽名並發出來的，因為別人假冒不了發送方的簽名。二是數字簽名能確定消息的完整性。

因為數字簽名的特點是它代表了文件的特徵，文件如果發生改變，數字摘要的值也將發生變化。不同的文件將得到不同的數字摘要。 一次數字簽名涉及到一個哈希函數、發送者的公鑰、發送者的私鑰。」

數字簽名技術是將摘要信息用發送者的私鑰加密，與原文一起傳送給接收者。接收者只有用發送者的公鑰才能解密被加密的摘要信息，然後用HASH函數對收到的原文產生一個摘要信息，與解密的摘要信息對比。如果相同，則說明收到的信息是完整的，在傳輸過程中沒有被修改，否則說明信息被修改過，因此數字簽名能夠驗證信息的完整性。

⑤ 數字簽名的基本原理是什麼

數字簽名是基於非對稱密鑰加密技術與數字摘要技術的應用，是一個包含電子文件信息以及發送者身份並能夠鑒別發送者身份以及發送信息是否被篡改的一段數字串。

一段數字簽名數字串包含了電子文件經過Hash編碼後產生的數字摘要，即一個Hash函數值以及發送者的公鑰和私鑰三部分內容。

數字簽名有兩個作用，一是能確定消息確實是由發送方簽名並發出來的。二是數字簽名能確定數據電文內容是否被篡改，保證消息的完整性。數字簽名的基本工作流程如下：

發送加密

1.數字簽名用戶發送電子文件時，發送方通過哈希函數對電子數據文件進行加密生成數據摘要（digest）；

2.數字簽名發送方用自己的私鑰對數據摘要進行加密，私鑰加密後的摘要即為數字簽名；

3.數字簽名和報文將一起發送給接收方。

接收解密

1.接收方首先用與發送方一樣的哈希函數從接收到的原始報文中計算出報文摘要；

2.接收方用發送方的提供的公鑰來對報文附加的數字簽名進行解密，得到一個數字摘要；

3.如果以上兩個摘要相一致，則可以確認文件內容沒有被篡改。

4.發送方的公鑰能夠對數字簽名進行解密，證明數字簽名由發送方發送。

以上過程逆向也可以進行，即當文件接受者想要回信時，可以先通過hash函數生成數字摘要，再用公鑰加密即可起到文件加密的作用，收信人（數字簽名擁有者）可以用私鑰解密查看文件數字摘要。

• 函數加密原理

Hash函數又叫加密散列函數，其特點在於正向輸出結果唯一性和逆向解密幾乎不可解，因此可用於與數據加密。

正向輸出容易且結果唯一：由數據正向計算對應的Hash值十分容易，且任何的輸入都可以生成一個特定Hash值的輸出，完全相同的數據輸入將得到相同的結果，但輸入數據稍有變化則將得到完全不同的結果。
Hash函數逆向不可解：由Hash值計算出其對應的數據極其困難，在當前科技條件下被視作不可能。

了解了數字簽名，我們順便來提一嘴數字證書的概念：

• 數字證書

由於網路上通信的雙方可能都不認識對方，那麼就需要第三者來介紹，這就是數字證書。數字證書由Certificate Authority( CA 認證中心)頒發。

首先A B雙方要互相信任對方證書。

然後就可以進行通信了，與上面的數字簽名相似。不同的是，使用了對稱加密。這是因為，非對稱加密在解密過程中，消耗的時間遠遠超過對稱加密。如果密文很長，那麼效率就比較低下了。但密鑰一般不會特別長，對對稱加密的密鑰的加解密可以提高效率。