前端加密的意義

這是一個繞不開的話題,肯定有很多看法.但我看來:前端加密看起來有意義,但有時候看起來并沒有意義. 但總體來看是有意義的,打個比喻:既然市面上大部分鎖都可以在20分鐘內(nèi)撬開，那門上裝鎖是否還有意義？

有意義:

在 HTTP 協(xié)議下，數(shù)據(jù)是明文傳輸，傳輸過程中網(wǎng)絡(luò)嗅探可直接獲取其中的數(shù)據(jù)。 如用戶的密碼和信用卡相關(guān)的資料，一旦被中間人獲取，會給用戶帶來極大的安全隱患。另一方面在非加密的傳輸過程中，攻擊者可更改數(shù)據(jù)或插入惡意的代碼等。那么前端加密的意義: 即在數(shù)據(jù)發(fā)送前將數(shù)據(jù)進(jìn)行哈希或使用公鑰加密。如果數(shù)據(jù)被中間人獲取，拿到的則不再是明文。
當(dāng)然還有其他一些優(yōu)點:例如避免后端等打印日志直接暴露明文密碼,還可以避免明文撞庫等.

沒有意義:

前端加密，其實只能防君子不能防小人。 前端系統(tǒng)的控制權(quán)是完全在用戶手里的，也就是說，前端做什么事情，用戶有完全的控制權(quán)。即使前端加密不可以防范中間人攻擊,包括HTTPS,因為中間還是存在著各種代理,客戶端代理,服務(wù)端代理.是很難做到不被劫持的.

這里簡單說下:

• 加密了也無法解決重放的問題，你發(fā)給服務(wù)器端的雖然是加密后的數(shù)據(jù)，但是黑客攔截之后，把加密之后的數(shù)據(jù)重發(fā)一遍，依然是驗證通過的。直接監(jiān)聽到你所謂的密文，然后用腳本發(fā)起一個http請求就可以登錄上去了。 http在網(wǎng)絡(luò)上是明文傳輸?shù)?，代理和網(wǎng)關(guān)都能夠看到所有的數(shù)據(jù)，在同一局域網(wǎng)內(nèi)也可以被嗅探到。加密也沒有提高什么攻擊難度，因為攻擊者就沒必要去解密原始密碼，能登錄上去就表示目標(biāo)已經(jīng)實現(xiàn)了，所以，難度沒有提高。

• 既然是加密，那么加密用的密鑰和算法肯定是保存在前端的，攻擊者通過查看源碼就能得到算法和密鑰。除非你是通過做瀏覽器插件，將算法和密鑰封裝在插件中，然后加密的時候明文混淆上時間戳，這樣即使黑客攔截到了請求數(shù)據(jù)，進(jìn)行重放過程時，也會很快失效。

總結(jié)一下:

• 1. 安全是前后端都需要做的事,不能前端加密了,后端就不管了.
• 2. HTTPS還是有必要的,只要正確使用了HTTPS連接和服務(wù)器端安全的哈希算法，密碼系統(tǒng)都可以是很安全的。

如果還有疑惑想深入探討的,可以看下某乎上的這篇文章

前端加密的幾種做法

? JavaScript 加密后傳輸(具體可以參考后面的常見加密方法)
? 瀏覽器插件內(nèi)進(jìn)行加密傳輸 (這個用得不是很多,這里暫不細(xì)究)
? Https 傳輸

加密算法

不同于哈希(后面會提到)，加密（Encrypt）是將目標(biāo)文本轉(zhuǎn)換成具有不同長度的、可逆的密文。也就是說加密算法是可逆的，而且其加密后生成的密文長度和明文本身的長度有關(guān)。所以如果被保護(hù)數(shù)據(jù)在以后需要被還原成明文，則需要使用加密。
在加密算法中又分為對稱加密（symmetric encryption）和非對稱加密（asymmetric encryption）。

（一）對稱加密（Symmetric Cryptography）

對稱加密是最快速、最簡單的一種加密方式，加密（encryption）與解密（decryption）用的是同樣的密鑰（secret key）。對稱加密有很多種算法，由于它效率很高，所以被廣泛使用在很多加密協(xié)議的核心當(dāng)中。

對稱加密通常使用的是相對較小的密鑰，一般小于256 bit。因為密鑰越大，加密越強(qiáng)，但加密與解密的過程越慢。如果你只用1bit來做這個密鑰，那黑客們可以先試著用0來解密，不行的話就再用1解；但如果你的密鑰有1MB大，黑客們可能永遠(yuǎn)也無法破解，但加密和解密的過程要花費(fèi)很長的時間。密鑰的大小既要照顧到安全性，也要照顧到效率，是一個trade-off。

2000年10月2日，美國國家標(biāo)準(zhǔn)與技術(shù)研究所（NIST-- American National Institute of Standards and Technology）選擇了Rijndael算法作為新的高級加密標(biāo)準(zhǔn)（AES-- Advanced Encryption Standard）。.NET中包含了Rijndael算法，類名叫RijndaelManaged，下面舉個例子。

加密過程：

private string myData = "hello"; 
private string myPassword = "OpenSesame"; 
private byte[] cipherText; 
private byte[] salt = { 
  0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x5, 0x4, 0x3, 0x2, 0x1, 0x0 
}; 
private void mnuSymmetricEncryption_Click(object sender, RoutedEventArgs e){ 
  var key = new Rfc2898DeriveBytes(myPassword, salt); 
  // Encrypt the data.
  var algorithm = new RijndaelManaged();
  algorithm.Key = key.GetBytes(16);
  algorithm.IV = key.GetBytes(16); 
  var sourceBytes = new System.Text.UnicodeEncoding().GetBytes(myData); 
  using (var sourceStream = new MemoryStream(sourceBytes)) 
  using (var destinationStream = new MemoryStream()) 
  using (var crypto = new CryptoStream(sourceStream, algorithm.CreateEncryptor(), CryptoStreamMode.Read)){
    moveBytes(crypto, destinationStream);
    cipherText = destinationStream.ToArray();
  }
  MessageBox.Show(String.Format(
    "Data:{0}{1}Encrypted and Encoded:{2}",myData,Environment.NewLine,Convert.ToBase64String(cipherText)
  ));
} 

private void moveBytes(Stream source, Stream dest){ 
  byte[] bytes = new byte[2048]; 
  var count = source.Read(bytes, 0, bytes.Length); 
  while (0 != count){
    dest.Write(bytes, 0, count);
    count = source.Read(bytes, 0, bytes.Length);
  }
}

解密過程：

private void mnuSymmetricDecryption_Click(object sender, RoutedEventArgs e){ 
  if (cipherText == null){
    MessageBox.Show("Encrypt Data First!"); 
    return;
  } 
  var key = new Rfc2898DeriveBytes(myPassword, salt); 
  // Try to decrypt, thus showing it can be round-tripped.
  var algorithm = new RijndaelManaged();
  algorithm.Key = key.GetBytes(16);
  algorithm.IV = key.GetBytes(16); 
  using (var sourceStream = new MemoryStream(cipherText)) 
  using (var destinationStream = new MemoryStream()) 
  using (var crypto = new CryptoStream(sourceStream, algorithm.CreateDecryptor(),CryptoStreamMode.Read)){
    moveBytes(crypto, destinationStream); 
    var decryptedBytes = destinationStream.ToArray(); 
    var decryptedMessage = new UnicodeEncoding().GetString(decryptedBytes);
    MessageBox.Show(decryptedMessage);
  }
}

常見的對稱加密算法有DES、3DES、Blowfish、IDEA、RC4、RC5、RC6和AES

注意: 因為前端的透明性，對于登錄密碼等敏感信息,就不要使用JavaScript來進(jìn)行對稱加密. 因為別人可以從前端得到密匙后,可以直接對信息進(jìn)行解密!

• 對稱加密的一大缺點是密鑰的管理與分配，換句話說，如何把密鑰發(fā)送到需要解密你的消息的人的手里是一個問題。在發(fā)送密鑰的過程中，密鑰有很大的風(fēng)險會被黑客們攔截。現(xiàn)實中通常的做法是將對稱加密的密鑰進(jìn)行非對稱加密，然后傳送給需要它的人。。

（二）非對稱加密（Asymmetric Cryptography）

非對稱加密為數(shù)據(jù)的加密與解密提供了一個非常安全的方法，它使用了一對密鑰，公鑰（public key）和私鑰（private key）。私鑰只能由一方安全保管，不能外泄，而公鑰則可以發(fā)給任何請求它的人。非對稱加密使用這對密鑰中的一個進(jìn)行加密，而解密則需要另一個密鑰。比如，你向銀行請求公鑰，銀行將公鑰發(fā)給你，你使用公鑰對消息加密，那么只有私鑰的持有人--銀行才能對你的消息解密。與對稱加密不同的是，銀行不需要將私鑰通過網(wǎng)絡(luò)發(fā)送出去，因此安全性大大提高。

目前最常用的非對稱加密算法是RSA算法，是Rivest, Shamir, 和Adleman于1978年發(fā)明，他們那時都是在MIT。.NET中也有RSA算法，請看下面的例子：

加密過程：

private byte[] rsaCipherText; private void mnuAsymmetricEncryption_Click(object sender, RoutedEventArgs e){ 
  var rsa = 1; 
  // Encrypt the data.
  var cspParms = new CspParameters(rsa);
  cspParms.Flags = CspProviderFlags.UseMachineKeyStore;
  cspParms.KeyContainerName = "My Keys"; 
  var algorithm = new RSACryptoServiceProvider(cspParms); 
  var sourceBytes = new UnicodeEncoding().GetBytes(myData);
  rsaCipherText = algorithm.Encrypt(sourceBytes, true);
  MessageBox.Show(String.Format(
    "Data: {0}{1}Encrypted and Encoded: {2}",myData,Environment.NewLine,Convert.ToBase64String(rsaCipherText)
  ));
}

解密過程：

private void mnuAsymmetricDecryption_Click(object sender, RoutedEventArgs e){ 
  if(rsaCipherText==null){
    MessageBox.Show("Encrypt First!"); 
    return;
  } 
  var rsa = 1; 
  // decrypt the data.
  var cspParms = new CspParameters(rsa);
  cspParms.Flags = CspProviderFlags.UseMachineKeyStore;
  cspParms.KeyContainerName = "My Keys"; 
  var algorithm = new RSACryptoServiceProvider(cspParms); 
  var unencrypted = algorithm.Decrypt(rsaCipherText, true);
  MessageBox.Show(new UnicodeEncoding().GetString(unencrypted));
}

常見的非對稱加密算法有：RSA、ECC（移動設(shè)備用）、Diffie-Hellman、El Gamal、DSA（數(shù)字簽名用）

雖然非對稱加密很安全，但是和對稱加密比起來，它非常的慢，所以我們還是要用對稱加密來傳送消息，但對稱加密所使用的密鑰我們可以通過非對稱加密的方式發(fā)送出去。為了解釋這個過程，請看下面的例子：

• Alice需要在銀行的網(wǎng)站做一筆交易，她的瀏覽器首先生成了一個隨機(jī)數(shù)作為對稱密鑰。
• Alice的瀏覽器向銀行的網(wǎng)站請求公鑰。
• 銀行將公鑰發(fā)送給Alice。
• Alice的瀏覽器使用銀行的公鑰將自己的對稱密鑰加密。
• Alice的瀏覽器將加密后的對稱密鑰發(fā)送給銀行。
• 銀行使用私鑰解密得到Alice瀏覽器的對稱密鑰。
• Alice與銀行可以使用對稱密鑰來對溝通的內(nèi)容進(jìn)行加密與解密了。

（三）總結(jié)

1.對稱加密加密與解密使用的是同樣的密鑰，所以速度快，但由于需要將密鑰在網(wǎng)絡(luò)傳輸，所以安全性不高。
2.非對稱加密使用了一對密鑰，公鑰與私鑰，所以安全性高，但加密與解密速度慢。
3.解決的辦法是將對稱加密的密鑰使用非對稱加密的公鑰進(jìn)行加密，然后發(fā)送出去，接收方使用私鑰進(jìn)行解密得到對稱加密的密鑰，然后雙方可以使用對稱加密來進(jìn)行溝通。

哈希加密算法

哈希算法（Hash）

哈希（Hash）是將目標(biāo)文本轉(zhuǎn)換成具有固定長度的字符串（或叫做消息摘要）。 當(dāng)輸入發(fā)生改變時，產(chǎn)生的哈希值也是完全不同的。從數(shù)學(xué)角度上講，一個哈希算法是一個多對一的映射關(guān)系，對于目標(biāo)文本 T，算法 H 可以將其唯一映射為R，并且對于所有的T，R具有相同的長度，所以 H 不存在逆映射，也就是說哈希算法是不可逆的。

• 基于哈希算法的特性，其適用于該場景：被保護(hù)數(shù)據(jù)僅僅用作比較驗證且不需要還原成明文形式。比較常用的哈希算法是 MD5 和 SHA1 。

• 我們比較熟悉的使用哈希存儲數(shù)據(jù)的例子是：當(dāng)我們登錄某個已注冊網(wǎng)站時，在忘記密碼的情況下需要重置密碼，此時網(wǎng)站會給你發(fā)一個隨機(jī)的密碼或者一個郵箱激活鏈接，而不是將之前的密碼發(fā)給你，這就是因為哈希算法是不可逆的。

需要注意的是：在 Web 應(yīng)用中，在瀏覽器中使用哈希加密的同時也要在服務(wù)端上進(jìn)行哈希加密。

服務(wù)端哈希加密原因: 一方面因為不需要將密文解密成明文來比對密碼，另一方面是一旦加密算法和密鑰泄露，那么整個用戶資料庫就相當(dāng)于明文存儲了。如果前端傳過來的是明文，那么在注冊時將其哈希，存入數(shù)據(jù)庫。登錄時，將密碼哈希和數(shù)據(jù)庫對應(yīng)的數(shù)據(jù)比對，若一致則說明密碼正確。

現(xiàn)在，對于簡單的哈希算法的攻擊方法主要有：尋找碰撞法和窮舉法。所以，為了保證數(shù)據(jù)的安全，可以在哈希算法的基礎(chǔ)上進(jìn)一步的加密，常見的方法有：加鹽、慢哈希、密鑰哈希、XOR 等。

加鹽（Adding Salt）

加鹽加密是一種對系統(tǒng)登錄口令的加密方式，它實現(xiàn)的方式是將每一個口令同一個叫做“鹽”（salt）的 n 位隨機(jī)數(shù)相關(guān)聯(lián)。

為了方便理解:這里引用這位同學(xué)的文章進(jìn)行說明

使用salt加密，它的基本想法是這樣的：

• 用戶注冊時，在密碼上撒一些鹽。生成一種味道，記住味道。
• 用戶再次登陸時，在輸入的密碼上撒鹽，聞一聞，判斷是否和原來的味道相同，相同就讓你吃飯。

由于驗證密碼時和最初散列密碼時使用相同的鹽值，所以salt的存儲在數(shù)據(jù)庫。并且這個值是由系統(tǒng)隨機(jī)產(chǎn)生的，而非硬編碼。這就保證了所要保護(hù)對象的機(jī)密性。

注冊時:

• 用戶注冊，系統(tǒng)隨機(jī)產(chǎn)生salt值。
• 將salt值和密碼連接起來，生產(chǎn)Hash值。
• 將Hash值和salt值分別存儲在數(shù)據(jù)庫中。

登陸時:

• 系統(tǒng)根據(jù)用戶名找到與之對應(yīng)的密碼Hash。
• 將用戶輸入密碼和salt值進(jìn)行散列。
• 判斷生成的Hash值是否和數(shù)據(jù)庫中Hash相同。

PS: 其實圖中的這種登錄也是不安全的. 原因是后面要提到的鹽值復(fù)用

使用加鹽加密時需要注意以下兩點：

• 短鹽值（Short Slat）

如果鹽值太短，攻擊者可以預(yù)先制作針對所有可能的鹽值的查詢表。例如，如果鹽值只有三個 ASCII 字符，那么只有 95x95x95=857,375 種可能性，加大了被攻擊的可能性。還有，不要使用可預(yù)測的鹽值，比如用戶名，因為針對某系統(tǒng)用戶名是唯一的且被經(jīng)常用于其他服務(wù)。

• 鹽值復(fù)用（Salt Reuse）

在項目開發(fā)中，有時會遇到將鹽值寫死在程序里或者只有第一次是隨機(jī)生成的，之后都會被重復(fù)使用，這種加鹽方法是不起作用的。以登錄密碼為例，如果兩個用戶有相同的密碼，那么他們就會有相同的哈希值，攻擊者就可以使用反向查表法對每個哈希值進(jìn)行字典攻擊，使得該哈希值更容易被破解。

所以正確的加鹽方法如下：

（1）鹽值應(yīng)該使用加密的安全偽隨機(jī)數(shù)生成器（ Cryptographically Secure Pseudo-Random Number Generator，CSPRNG ）產(chǎn)生，比如 C 語言的 rand() 函數(shù)，這樣生成的隨機(jī)數(shù)高度隨機(jī)、完全不可預(yù)測；

（2）鹽值混入目標(biāo)文本中，一起使用標(biāo)準(zhǔn)的加密函數(shù)進(jìn)行加密；

（3）鹽值要足夠長（經(jīng)驗表明：鹽值至少要跟哈希函數(shù)的輸出一樣長）且永不重復(fù)；

（4）鹽值最好由服務(wù)端提供，前端取值使用。

慢哈希函數(shù)（Slow Hash Function）

顧名思義，慢哈希函數(shù)是將哈希函數(shù)變得非常慢，使得攻擊方法也變得很慢，慢到足以令攻擊者放棄，而往往由此帶來的延遲也不會引起用戶的注意。降低攻擊效率用到了密鑰擴(kuò)展（ key stretching）的技術(shù)，而密鑰擴(kuò)展的實現(xiàn)使用了一種CPU 密集型哈希函數(shù)（ CPU-intensive hash function）?？雌饋碛悬c暈~還是關(guān)注下該函數(shù)怎么用吧！

如果想在一個 Web應(yīng)用中使用密鑰擴(kuò)展，則需要設(shè)定較低的迭代次數(shù)來降低額外的計算成本。我們一般直接選擇使用標(biāo)準(zhǔn)的算法來完成，比如PBKDF2或bcrypt。PHP、斯坦福大學(xué)的 JavaScript加密庫都包含了 PBKDF2的實現(xiàn)，瀏覽器中則可以考慮使用 JavaScript 完成，否則這部分工作應(yīng)該由服務(wù)端進(jìn)行計算。

密鑰哈希

密鑰哈希是將密鑰添加到哈希加密，這樣只有知道密鑰的人才可以進(jìn)行驗證。目前有兩種實現(xiàn)方式：使用 ASE 算法對哈希值加密、使用密鑰哈希算法HMAC 將密鑰包含到哈希字符串中。為了保證密鑰的安全，需要將其存儲在外部系統(tǒng)（比如一個物理上隔離的服務(wù)端）。

即使選擇了密鑰哈希，在其基礎(chǔ)上進(jìn)行加鹽或者密鑰擴(kuò)展處理也是很有必要。目前密鑰哈希用于服務(wù)端比較多，例如來應(yīng)對常見的 SQL注入攻擊。

XOR

XOR它指的是邏輯運(yùn)算中的“異或運(yùn)算”。兩個值相同時，返回false，否則返回 true，用來判斷兩個值是否不同。
JavaScript語言的二進(jìn)制運(yùn)算，有一個專門的 XOR 運(yùn)算符，寫作^。

1 ^ 1 // 0

0 ^ 0 // 0

1 ^ 0 // 1

0 ^ 1 // 1

XOR 運(yùn)算有一個特性：如果對一個值連續(xù)做兩次 XOR，會返回這個值本身。這也是其可以用于信息加密的根本。

message XOR key // cipherText

cipherText XOR key // message

目標(biāo)文本 message，key 是密鑰，第一次執(zhí)行 XOR 會得到加密文本；在加密文本上再用 key 做一次 XOR 就會還原目標(biāo)文本 message。為了保證 XOR 的安全，需要滿足以下兩點：

（1）key 的長度大于等于 message ；

（2）key 必須是一次性的，且每次都要隨機(jī)產(chǎn)生。

下面以登錄密碼加密為例介紹下 XOR 的使用：

• 第一步：使用 MD5 算法，計算密碼的哈希；

const message = md5(password);

• 第二步：生成一個隨機(jī) key 值；

• 第三步：進(jìn)行 XOR 運(yùn)算，求出加密后的 message。

function getXOR(message, key) {
  const arr = [];

  //假設(shè) key 是32位的

  for (let i = 0; i < 32; i++) {
    const  m = parseInt(message.substr(i, 1), 16);
    const k = parseInt(key.substr(i, 1), 16);
    arr.push((m ^ k).toString(16));
  }
  return arr.join('');
}

如上所示，使用 XOR 和一次性的密鑰 key 對密碼進(jìn)行加密處理，只要 key 沒有泄露，目標(biāo)文本就不會被破解。

上面說了那么多，問題就來了：我們應(yīng)該使用什么樣的哈希算法呢？

（1）選擇經(jīng)過驗證的成熟算法，如 PBKDF2 等 ；

（2）crypt 的安全版本；

（3）避免使用自己設(shè)計的加密算法。

HMAC

對于HMAC算法,我也不是太了解.看了幾篇文章,感覺和加鹽很像,就是salt換成后端隨機(jī)生成的(好像可以防止重放攻擊).然后再通過HMAC算法,得到摘要.

關(guān)于HMAC算法部分可以詳細(xì)看這篇文章,我是學(xué)渣,看了半天也不是太懂.=.=

大概過程如下:

• 1.客戶端發(fā)出登錄請求
• 2.服務(wù)器返回一個隨機(jī)值，在會話記錄中保存這個隨機(jī)值
• 3.客戶端將該隨機(jī)值作為密鑰，用戶密碼進(jìn)行 hmac 運(yùn)算，遞交給服務(wù)器
• 4.服務(wù)器讀取數(shù)據(jù)庫中的用戶密碼，利用密鑰做和客戶端一樣的 hmac運(yùn)算，然后與用戶發(fā)送的結(jié)果比較，如果一致，則用戶身份合法。

好處:

• 與自定義的加salt算法不同，Hmac算法針對所有哈希算法都通用，無論是MD5還是SHA-1。采用Hmac替代我們自己的salt算法，可以使程序算法更標(biāo)準(zhǔn)化，也更安全。(摘自雪峰大佬的這篇文章)
• 另外一個就是密碼的安全性,由于不知道密鑰，所以不可能獲取到用戶密碼

補(bǔ)充1: 結(jié)合驗證碼進(jìn)行前端加密 (其實就是一種動態(tài)加鹽哈希)

• 前端先將密碼哈希，然后和用戶輸入的驗證碼進(jìn)行哈希，得到的結(jié)果作為密碼字段發(fā)送給服務(wù)器。服務(wù)器先確認(rèn)驗證碼正確，然后再進(jìn)行密碼驗證，否則直接返回驗證碼錯誤信息。

• 這種實踐保證了密碼在傳輸過程中的資料安全，即使攻擊者拿到了數(shù)據(jù)也無法重放。圖形化驗證碼更是增加了難度。另一方面該實踐大大增加了撞庫的成本。

前端加密一定程度保障了傳輸過程中的資料安全，那么會不會有對兩端（客戶端和服務(wù)器）有安全幫助呢？
有幫助，使用一些前端加密手段，可以增加拖庫后的數(shù)據(jù)破解難度。但是驗證碼方法不具有這樣的功能，因為數(shù)據(jù)庫存的仍是明文密碼哈希后的結(jié)果，那么攻擊者可以繞過前端加密，可以直接暴力破解。

補(bǔ)充2: Base64 編碼

大家經(jīng)常說的是 Base64 加密，有 Base64 加密嗎？真木有，只有 Base64 編碼。

Base64 是一種基于 64 個可打印字符來表示二進(jìn)制數(shù)據(jù)的表示方法。常用于在通常處理文本數(shù)據(jù)的場合，表示、傳輸、存儲一些二進(jìn)制數(shù)據(jù),包括 MIME 的 email，email via MIME，在 XML 中存儲復(fù)雜數(shù)據(jù)；主要用來解決把不可打印的內(nèi)容塞進(jìn)可打印內(nèi)容的需求。js中 base64 方法使用如下：

//1.編碼
var result = Base.encode('shotCat好帥!');  //--> "c2hvdENhdOWlveW4hSE="

//2.解碼
var result2 = Base.decode(result); //--> 'shotCat好帥!' 沒錯,我就是這么不要臉!!!

因此，Base64 適用于小段內(nèi)容的編碼，比如數(shù)字證書簽名、Cookie的內(nèi)容等；而且 Base64 也是一種通過查表的編碼方法，不能用于加密，如果需要加密，請使用專業(yè)的加密算法。

PS: 對于前端來說,base64用得最多的也就是圖片轉(zhuǎn)碼吧.

補(bǔ)充3: 數(shù)字簽名

數(shù)字簽名主要用于:確認(rèn)信息來源于特定的主體且信息完整、未被篡改，發(fā)送方生成簽名，接收方驗證簽名。

發(fā)送方: 首先計算目標(biāo)文本的摘要（哈希值），通過私鑰對摘要進(jìn)行簽名，將目標(biāo)文本和電子簽名發(fā)送給接收方。

接收方: 驗證簽名的步驟如下：

• 1,通過公鑰破解電子簽名，得到摘要 D1 (如果失敗，則信息來源主體校驗失敗)；
• 2,計算目標(biāo)文本摘要 D2；
• 3,若 D1 === D2，則說明目標(biāo)文本完整、未被篡改。

數(shù)字簽名與非對稱加密區(qū)別:

• 非對稱加密（加密/解密）：公鑰加密，私鑰解密。
• 數(shù)字簽名（簽名/驗證）：私鑰簽名，公鑰驗證。

HTTPS加密

為了避免重復(fù),這部分內(nèi)容在本系列HTTP與HTTPS有詳細(xì)介紹