讀《圖解密碼技術》(三):密鑰、隨機數和應用技術

原創文章，轉載請註明：轉載自Keegan小鋼

並標明原文連接：http://keeganlee.me/post/reading/20160722

微信訂閱號：keeganlee_me

寫於2016-07-22

---

讀《圖解密碼技術》(一):密碼

讀《圖解密碼技術》(二):認證

讀《圖解密碼技術》(三):密鑰、隨機數和應用技術

---

最後一篇了，若是還沒看過前兩篇的，最好先翻回去看看，由於這最後一篇的內容是創建在前兩篇的基礎之上的。本篇的內容包括密鑰、隨機數、PGP、SSL/TLS，最後再講講密碼技術的現狀和侷限性，以及簡單介紹一下量子密碼和量子計算機。

密鑰

在使用對稱密碼、公鑰密碼、消息認證碼、數字簽名等密碼技術時，都須要密鑰。密鑰長度通常不能過短，過短意味着密鑰空間過小，那麼，進行暴力破解就很容易。

DES的密鑰長度爲56比特(7字節)，密鑰空間爲2^56，在現有的計算能力下，仍是比較容易被暴力破解的。三重DES的DES-EDE3的密鑰長度爲168比特(21字節)，是DES的密鑰長度的三倍多，可是密鑰空間可不是三倍這麼簡單，DES-EDE3的密鑰空間爲2^168，整整是DES密鑰空間的2^112倍，這麼大的密鑰空間，以現有的計算能力，還沒法在現實的時間裏被暴力破解。AES的密鑰長度則能夠從12八、192和256比特中進行選擇，三者的密鑰空間也是不小的。

密鑰和明文實際上是等價的，由於對攻擊者來講，獲得密鑰就等價於獲得明文。

各類不一樣的密鑰

從前兩篇文章咱們就知道，密鑰分不少種類，這裏咱們作一下整理。

在對稱密碼中，加密和解密使用的是相同的共享密鑰。而在公鑰密碼中，加密用的是公鑰，解密用的則是私鑰，相對應的公鑰和私鑰組爲密鑰對。消息認證碼使用的也是共享密鑰。而數字簽名使用的和公鑰密碼同樣是密鑰對，用私鑰簽名，用公鑰驗證簽名。混合密碼系統中還使用了一次性密鑰，稱爲會話密鑰。而相對於每次通訊都更換的會話密鑰，一直被重複使用的密碼則稱爲主密鑰。用於加密內容的密鑰稱爲CEK(Contents Encrypting Key，內容加密密鑰)；相對地，用於加密密鑰的密鑰則稱爲KEK(Key Encrypting Key，密鑰加密密鑰)。CEK 和 KEK 的用法能夠以下圖所示：

在不少狀況下，會話密鑰都是被做爲 CEK 使用的，而主密鑰則是被做爲 KEK 使用的。

密鑰的管理

生成密鑰最好的方法就是使用真正的隨機數，由於密鑰須要具有不可預測性。不過，通常咱們都是使用僞隨機數生成器來生成密鑰。另外，密碼學用途的僞隨機數生成器必須是專門針對密碼學用途而設計的。畢竟，生成僞隨機數的算法不少，但有些並不具有不可預測性。

有時咱們也會使用容易記住的口令(password 或 passphrase)來生成密鑰。passphrase 指的是一種由多個單詞組成的較長的 passwrod，在此將二者統稱爲口令。嚴格來講，不多直接用口令來做爲密鑰使用，通常都是將口令輸入單向散列函數，而後將獲得的散列值做爲密鑰使用。而在使用口令生成密鑰時，爲了防止字典攻擊，須要在口令上面附加一串稱爲鹽(salt)的隨機數，而後再將其輸入單向散列函數。這種方法稱爲「基於口令的密碼」(Password Based Encryption, PBE)。關於 PBE 稍後再詳細介紹。

對於共享密鑰，就會存在密鑰配送問題。在密碼篇就提到幾種解決方案：事先共享密鑰、使用密鑰分配中心、使用公鑰密碼、Diffie-Hellman密鑰交換。關於Diffie-Hellman密鑰交換的原理，以前的文章沒講，在本篇稍後會詳細介紹。

爲了提升通訊的機密性，還能夠採用密鑰更新(key updating)的方法。這種方法就是在使用共享密鑰進行通訊的過程當中，按期改變密鑰。例如，在更新密鑰時，發送者和接收者使用單向散列函數計算當前密鑰的散列值，並將這個散列值用做新的密鑰。簡單說，就是用當前密鑰的散列值做爲下一個密鑰。

除了只使用一次的會話密鑰，其餘密鑰基本都須要考慮保存密鑰的問題。尤爲對於共享密鑰來講，不少應用都須要將密鑰保存在客戶端，例如移動App，要麼將密鑰硬編碼在代碼裏，或者保存在文件中，但不管哪一種方式，應用一旦被反編譯，密鑰就存在泄漏的風險。以防密鑰被盜，可使用將密鑰加密後保存的方法。但要將密鑰加密，必然須要另外一個密鑰，即 KEK。那麼，KEK 又如何保存？這問題還真很差解決。不過，對密鑰進行加密的方法卻能夠減小須要保管的密鑰數量。好比，假設平臺系統接入了10萬個應用，每一個應用都有一個本身的密鑰，即系統須要保管10萬個密鑰。那麼，用 KEK 對這10萬個密鑰進行加密，這樣的話只要保管這一個 KEK 就能夠了。便是說，不須要確保多個密鑰(CEK)的機密性，而只須要確保一個密鑰(KEK)的機密性就能夠了。這和認證機構的層級化很是類似。在後者中，咱們不須要信任多個認證機構，而只須要信任一個根 CA 就能夠了。

Diffie-Hellman密鑰交換

經過Diffie-Hellman密鑰交換算法，通訊雙方僅經過交換一些能夠公開的信息就可以生成出共享的祕密數字，而這一祕密數字就能夠被用做對稱密碼的密鑰。雖然這種方法名字叫「密鑰交換」，但實際上雙方並無真正交換密鑰，而是經過計算生成出了一個相同的共享密鑰。所以，這種方法也稱爲 Diffie-Hellman密鑰協商。

Diffie-Hellman密鑰交換的步驟以下：

1. Alice 向 Bob 發送兩個質數 P 和 G

   P 必須是一個很是大的質數，而 G 則是一個和 P 相關的數，稱爲生成元(generator)。G 能夠是一個較小的數字。

2. Alice 生成一個隨機數 A

   A 是一個 1 ~ P-2 之間的整數。這個數是一個只有 Alice 知道的祕密數字。

3. Bob 生成一個隨機數 B

   B 也是一個 1 ~ P-2 之間的整數。這個數是一個只有 Bob 才知道的祕密數字。

4. Alice 將 G^A mod P 計算結果的數發送給 Bob

5. Bob 將 G^B mod P 計算結果的數發送給 Alice

6. Alice 用 Bob 發過來的數計算 A 次方並求 mod P

   這個數就是共享密鑰。Alice 計算的密鑰 = (G^B mod P)^A mod P = G^(A*B) mod P

7. Bob 用 Alice 發過來的數計算 B 次方並求 mod P

   Bob 計算的密鑰 = (G^A mod P)^B mod P = G^(A*B) mod P = Alice 計算的密鑰。可見兩方計算的密鑰是相等的。

關於第1步提到的生成元是什麼呢？先來看一張表，假設 P = 13：

其中，二、六、七、11都是13的生成元。這幾個數有什麼性質呢？從上表能夠發現，這幾個數的乘方結果中都出現了1~12的所有整數。也就是說，P 的生成元的乘方結果與 1 ~ P-1 中的數字是一一對應的。正是由於具備這樣一一對應的關係，Alice 纔可以從 1 ~ P-2 的範圍中隨機選擇一個數字(之因此不能選擇 P-1，是由於 G^(P-1) mod P 的值必定是等於1的)。

最後，須要清楚，針對Diffie-Hellman密鑰交換是能夠發動中間人攻擊的。而爲了防止中間人攻擊，可使用數字簽名、證書等方法來應對。

基於口令的密碼(PBE)

基於口令的密碼(Password Based Encryption，PBE)就是一種根據口令生成密鑰並用該密鑰進行加密的方法。

PBE 的加密能夠用下圖來表示：

主要有三個步驟：

1. 生成 KEK

   首先，經過僞隨機數生成器生成一個被稱爲鹽(salt)的隨機數。而後，將鹽和口令一塊兒輸入單向散列函數，輸出的結果就是 KEK。鹽是一種用於防護字典攻擊的機制。

2. 生成會話密鑰並加密

   會話密鑰 CEK 也是經過僞隨機數生成器來生成，生成以後使用 KEK 對其進行加密，而後將加密後的會話密鑰和鹽一塊兒保存在安全的地方。

3. 加密消息

   最後，使用 CEK 對消息進行加密。

而 PBE 解密的過程則以下圖：

解密主要也是有三個步驟：

1. 重建KEK

   將以前保存下來的鹽和口令一塊兒輸入單向散列函數，獲得的散列值就是 KEK 了。

2. 解密會話密鑰

   再將以前保存下來的已加密的會話密鑰用 KEK 進行解密，就能獲得會話密鑰 CEK 了。

3. 解密消息

   最後，用已解密的 CEK 對密文進行解密便可。

另外，在生成 KEK 時，經過屢次使用單向散列函數能夠提升安全性。

隨機數

有哪些場景使用到隨機數呢？主要可能有如下這些：

• 生成密鑰
• 生成密鑰對
• 生成初始化向量(IV)
• 生成nonce
• 生成鹽

隨機數的性質主要分爲三類：

• 隨機性：不存在統計學誤差，是徹底雜亂的數列。
• 不可預測性：不能從過去的數列推測出下一個出現的數。
• 不可重現性：除非將數列自己保存下來，不然不能重現相同的數列。

上面三個性質中，越往下就越嚴格。具有隨機性，不表明必定具有不可預測性。具有不可預測性的數列，則必定具有隨機性。具有不可重現性的數列，也必定具有不可預測性和隨機性。在書中，將這三個性質的隨機數按順序分別命名爲「弱僞隨機數」、「強僞隨機數」和「真隨機數」。

僞隨機數生成器

隨機數能夠經過硬件來生成，也能夠經過軟件來生成。經過硬件生成的隨機數列通常都是真隨機數，是從不可重現的物理現象中獲取信息而生成數列的，好比周圍的溫度和聲音的變化、用戶移動鼠標的位置信息、鍵盤輸入的時間間隔、放射線測量儀的輸出值等。像這樣的硬件設備稱爲隨機數生成器(Random Number Generator，RNG)。而生成隨機數的軟件則稱爲僞隨機數生成器(Pseudo Random Number Generator，PRNG)。由於僅靠軟件沒法生成真隨機數，由於要加上一個「僞」字。

僞隨機數生成器具備「內部狀態」，並根據外部輸入的「種子」來生成僞隨機數列，以下圖：

僞隨機數生成器的內部狀態，是指僞隨機數生成器所管理的內存中的數值。這個數值在每次生成隨機數後都會改變。而種子是用來初始化內部狀態的。僞隨機數生成器是公開的，但種子是須要保密的，這就好像密碼算法是公開的，但密鑰是保密的。

具體的僞隨機數生成器

具體的僞隨機數生成器有不少，書中介紹了五種：雜亂的方法、線性同餘法、單向散列函數法、密碼法、ANSI X9.17。

• 雜亂的方法

  雜亂的方法就是使用雜亂無章的算法來生成隨機數，但這種方法其實並不可取。一是由於複雜算法所生成的數列大多數具備很短的週期(即短數列的不斷重複)；二是由於若是程序員不可以理解算法的詳細內容，那麼就沒法判斷所生成的隨機數是否具有不可預測性。

• 線性同餘法

  線性同餘法就是將當前的僞隨機數值乘以 A 再加上 C，而後將除以 M 獲得的餘數做爲下一個僞隨機數。其中，A、C、M都是常量，且 A 和 C 須要小於 M。C 語言的庫函數 rand，以及Java 的 Random 類，都採用了線性同餘法。線性同餘法並不具有不可預測性，所以不能夠用於密碼技術。

  

• 單向散列函數法

  使用單向散列函數能夠編寫出具有不可預測性的僞隨機數列(即強僞隨機數)的僞隨機數生成器。單向散列函數的單向性是支撐僞隨機數生成器不可預測性的基礎。

  

• 密碼法

  也可使用密碼來編寫可以生成強僞隨機數的僞隨機數生成器。既可使用 AES 等對稱密碼，也可使用 RSA 等公鑰密碼。密碼的機密性是支撐僞隨機數生成器不可預測性的基礎。

  

• ANSI X9.17

  ANSI X9.17 僞隨機數生成器的結構則有點複雜，PGP 密碼軟件就使用了這種方法。

  

PGP

PGP 將多種密碼技術進行了完美的組合，其具有了現代密碼軟件所必需的幾乎所有功能，包括但不限於：對稱密碼、公鑰密碼、數字簽名、單向散列函數、證書、壓縮、大文件的拆分和拼合、鑰匙串管理等。

生成密鑰對

要在 PGP 中進行加密和數字簽名，須要先生成本身的密鑰對。下圖展現了從命令行生成密鑰的過程，其中，粗體爲用戶輸入的內容：

加密和解密

使用 PGP 進行加密的過程以下圖所示：

而解密的過程則以下：

PGP 的私鑰是保存在用戶的鑰匙串中的。另外，私鑰都是以加密狀態保存的，並在保存時使用了基於口令的密碼(PBE)。

生成和驗證數字簽名

生成數字簽名的過程以下圖：

而驗證簽名的過程則以下圖：

生成數字簽名並加密以及解密並驗證數字簽名

如何將密碼和數字簽名進行組合，下面兩張圖是整本書最複雜的，但它只不過是將以前講解的內容組合起來了而已。

下圖是生成數字簽名並加密的過程：

而下圖則是解密並驗證數字簽名的過程：

信任網

如何確認公鑰的合法性？前面介紹的證書是一種方法。對公鑰的信任是創建在對認證機構的信任的基礎之上的。不過，PGP 卻沒有使用認證機構，而是採用了一種叫作信任網(也稱爲信任圈或好友圈)的方法。信任網的要點是「不依賴認證機構，而是創建每一個人之間的信任關係」。換言之，就是可以本身決定要信任哪些公鑰。

PGP 當初的設計目的是在連國家都不可信的狀況下依然可以使用，所以它並不關心有沒有可信的認證機構，而是採用了「由用戶本身來決定信任誰」這樣的設計。

須要注意，「公鑰是否合法」與「全部者是否可信」是兩個不一樣的問題，由於儘管公鑰合法，其全部者也能夠是不可信的。例如，Alice認爲從Bob那得到的公鑰是合法的，由於這個公鑰是Bob當面交給Alice的。可是Alice不信任Bob在數字簽名上的判斷能力，即使Bob對其餘的公鑰進行了數字簽名，Alice也會懷疑Bob是否真的進行了本人確認。

在 PGP 中，信任級別能夠分爲四種：絕對信任、徹底信任、有限信任和不信任。

SSL/TLS

SSL/TLS也是綜合運用了對稱密碼、公鑰密碼、消息認證碼、數字簽名、僞隨機數生成器等密碼技術。而咱們知道SSL/TLS最普遍的應用就是套接在HTTP上，但實際上，SSL/TLS還能夠套接在其餘網絡協議之上的，例如，SMTP 和 POP3 之類的電子郵件協議。由於如今普遍使用的是TLS協議，所以下文只以TLS協議爲主。

TLS安全協議可分爲兩層：TLS記錄協議和TLS握手協議。TLS記錄協議在TLS握手協議的下層，負責數據封裝、壓縮、加密等功能。而TLS握手協議則用於在實際的數據傳輸開始前，通訊雙方進行身份認證、協商加密算法、交換密鑰等。TLS握手協議又分爲4個子協議：握手協議、密碼規格變動協議、警告協議和應用數據協議。TLS協議的層次結構以下圖：

TLS記錄協議

TLS記錄協議的處理過程以下圖：

首先，消息被分割成多個片斷，而後分別對每一個片斷進行壓縮。壓縮算法須要與通訊對象協商決定。接下來，通過壓縮的片斷會被加上消息認證碼，這就能夠保證完整性，並進行數據的認證。同時，爲了防止重放攻擊，在計算消息認證碼時，還加上了片斷的編號。單向散列函數的算法，以及消息認證碼所使用的密鑰都須要與通訊對象協商決定。再接下來，就是加密了。加密使用CBC模式，CBC模式的初始化向量(IV)經過主密碼生成，而對稱密碼的算法和共享密鑰也是須要與通訊對象協商決定。最後，密文再加上數據類型、版本號、壓縮後的長度組成的報頭就是最終的報文數據。其中，數據類型爲TLS握手協議中的4個子協議之一。

TLS握手協議

TLS握手協議可分爲4個子協議，其中，握手協議是最複雜的一個子協議，其過程以下圖：

1. ClientHello(客戶端->服務器)

客戶端向服務器發送ClientHello消息，消息內容主要包括：可用的版本號、當前時間、客戶端隨機數、會話ID、可用的密碼套件清單、可用的壓縮方式清單。複製代碼

2. ServerHello(服務器->客戶端)

對於客戶端發送的ClientHello消息，服務器會返回一個ServerHello消息，消息內容主要包括：使用的版本號、當前時間、服務器隨機數、會話ID、使用的密碼套件、使用的壓縮方式。這一步肯定了通訊中使用的「版本號」、「密碼套件」和「壓縮方式」。複製代碼

3. Certificate(服務器->客戶端)

服務器再向客戶端發送Certificate消息，主要是**證書清單**。首先發送的是服務器的證書，而後會按順序發送對服務器證書籤名的認證機構的證書。複製代碼

4. ServerKeyExchange(服務器->客戶端)

當Certificate消息不足以知足需求時，服務器會向客戶端發送ServerKeyExchange消息。具體所發送的消息內容會根據所使用的密碼套件而有所不一樣。複製代碼

5. CertificateRequest(服務器->客戶端)

CertificateRequest消息用於服務器向客戶端請求證書，這是爲了進行**客戶端認證**。消息內容還包括：服務器可以理解的證書類型清單和認證機構名稱清單。當不使用客戶端認證時，不會發送CertificateRequest消息。複製代碼

6. ServerHelloDone(服務器->客戶端)

服務器發送ServerHelloDone消息則表示從ServerHello消息開始的一系列消息的結束。複製代碼

7. Certificate(客戶端->服務器)

當服務器發送了CertificateRequest消息時，則客戶端會發送Certificate消息，將本身的證書同消息一塊兒發送給服務器。若是服務器沒有發送CertificateRequest消息，客戶端則不會發送Certificate消息。複製代碼

8. ClientKeyExchange(客戶端->服務器)

客戶端發送ClientKeyExchange消息。當密碼套件中保護RSA時，會隨消息一塊兒發送**通過加密的預備主密碼**。當密碼套件中包含Diffie-Hellman密鑰交換時，會隨消息一塊兒發送**Diffie-Hellman的公開值**。預備主密碼是由客戶端生成的隨機數，以後會被用做生成主密碼的種子。根據預備主密碼，服務器和客戶端會計算出相同的**主密碼**，而後再根據主密碼生成：對稱密碼的密鑰、消息認證碼的密鑰、對稱密碼的CBC模式中使用的初始化向量(IV)。複製代碼

9. CertificateVerify(客戶端->服務器)

客戶端只有在服務器發送CertificateRequest消息時纔會發送CertificateVerify消息。這個消息的目的是向服務器證實本身的確持有客戶端證書的私鑰。爲了實現這一目的，客戶端會計算「主密碼」和「握手協議中傳送的消息」的散列值，並加上本身的數字簽名後發送給服務器。複製代碼

10. ChangeCipherSpec(客戶端->服務器)

客戶端發送ChangeCipherSpec消息表示要切換密碼。實際上，這不是握手協議的消息，而是密碼規格變動協議的消息。在ChangeCipherSpec消息以前，客戶端和服務器之間以及交換了全部關於密碼套件的信息，所以在收到這一消息時，客戶端和服務器會同時切換密碼。在這一消息以後，TLS記錄協議就開始使用雙方協商決定的密碼通訊方式了。複製代碼

11. Finished(客戶端->服務器)

客戶端發送Finished消息表示握手協議到此結束。這個消息實際上是使用切換後的密碼套件來發送的。實際負責加密操做的是TLS記錄協議。複製代碼

12. ChangeCipherSpec(服務器->客戶端)

此次輪到服務器發送ChangeCipherSpec消息了，代表服務器要切換密碼了。複製代碼

13. Finished(服務器->客戶端)

服務器也一樣發送Finished消息代表握手協議到此結束。這個消息一樣使用切換後的密碼套件來發送。實際負責加密操做的也是TLS記錄協議。複製代碼

14. 切換至應用數據協議

在此以後，客戶端和服務器會使用應用數據協議和TLS記錄協議進行密碼通訊。複製代碼

從結果來看，握手協議完成了下列操做：

• 客戶端得到了服務器的合法公鑰，完成了服務器認證。
• 服務器得到了客戶端的合法公鑰，完成了客戶端認證(當須要客戶端認證時)。
• 客戶端和服務器生成了密碼通訊中使用的共享密鑰。
• 客戶端和服務器生成了消息認證碼中使用的共享密鑰。

除了握手協議，其餘3各子協議都很簡單。密碼規格變動協議用於密碼切換的同步。簡單地說，就跟向對方喊「一、二、3！」差很少。當協議中途發生錯誤時，就會經過警告協議傳達給對方。警告協議負責在發生錯誤時將錯誤傳達給對方。若是沒有發生錯誤，則會使用應用數據協議來進行通訊。應用數據協議用於和通訊對象之間傳送應用數據。當TLS套接在HTTP時，HTTP的請求和相應就會經過TLS的應用數據協議和TLS記錄協議來進行傳送。

密碼技術與現實社會

前面講到的6種基本的密碼技術可整理成下圖：

書中屢次使用了框架這個說法。框架的特色就是可以對其中做爲組成元素的技術進行替換，就像更好零件同樣。例如，消息認證碼算法HMAC的設計就容許對單向散列函數的算法進行替換。在PGP中，對稱密碼、公鑰密碼、單向散列函數等都是能夠替換的。在SSL/TLS中，客戶端和服務器能夠經過握手協議進行通訊，並當場決定所使用的密碼套件。使用框架可以提升密碼技術系統的重用性，也可以提升系統的強度。經過將單獨的密碼技術像零件同樣組合起來，並根據須要進行替換，可以實現更長期的、更高的安全性。

另外，全部密碼技術其實也能夠當作是一種「壓縮技術」，以下表所示：

量子密碼和量子計算機

量子密碼是基於量子理論的通訊技術，是一種讓通訊自己不可竊聽的技術，也能夠理解爲是一種利用光子的量子特性來實現通訊的方法。最先的量子密碼中，利用了兩個事實：
1. 從原理上說，沒法準確測出光子的偏振方向

根據這一事實，可讓竊聽者獲得的內容變得不正確。複製代碼

2. 測量行爲自己會致使光子的狀態發送改變

根據這一事實，接收者能夠判斷出通訊是否被竊聽。複製代碼

而量子計算機則有着超強的計算能力。若是有了量子計算機，那現有的全部密碼都可以瞬間被暴力破解。根據量子理論，粒子可同時具備多種狀態。若是使用具備多種狀態的粒子進行計算，則能夠同時完成多種狀態的計算。若是用1個粒子可以計算0和1兩種狀態，那麼用128個這樣的粒子就能夠同時計算2^128中狀態。換句話說，就是一臺超級並行計算機。

若是量子密碼比量子計算機先進入實用領域，則可使用量子密碼來實現一次性密碼本，從而產生完美的密碼技術。因爲一次性密碼本在原理上是沒法破譯的，所以即便用量子計算機也沒法破譯量子密碼。然而，若是量子計算機比量子密碼先進入實用領域，則實用目前的密碼技術所產生的密文將會所有被破譯。

只有完美的密碼，沒有完美的人

就算量子密碼進入實用領域，也不能實現完美的安全。由於在安全問題中，密碼技術可以覆蓋的範圍是很是有限的。在確保系統的總體安全方面，人是一個特別巨大的弱點。

爲了配送對稱密碼的密鑰，咱們須要使用公鑰密碼，而爲了對公鑰進行認證，咱們又須要認證機構的公鑰。以此類推，無窮無盡，咱們必須在某個節點上找到一個公鑰是本身可以徹底信任的，也就是必需要有一個信任的種子。

經過密碼技術，咱們能夠提升機密性，也可以讓認證變得更加容易，可是這並不意味着咱們能夠實現完美的機密性和完美的認證。

就算經過人的指紋、聲紋、面容識別等生物識別認證也並非完美的認證。要進行生物識別認證，就必須在某個時間點上將生物信息轉換爲比特序列，而實際的認證則是經過轉換後的比特序列來完成的。所以，若是這些比特序列被竊取，就會和鑰匙被偷產生相同的後果。

另外，「防護必須完美無缺，攻擊只需突破一點」。爲了保衛系統安全，咱們必須應對各類可能的攻擊，並且這種防護必須24小時連續工做。另外一方面，要攻擊一個系統，則只要找到一種有效的攻擊方法，並且只需利用防護方一瞬間的破綻就能夠完成了。

寫在最後

其實，在實際應用中，安全問題所涉及的技術，遠比這本書裏所講到的密碼技術多得多，也複雜得多。例如，App的加殼保護、OAuth認證等。在實際的應用中，還須要考慮更多，好比，安全性和性能之間須要平衡。雖然，懂得了這些密碼技術，並不意味着就能設計出很是安全的系統。可是，若是不懂這些密碼技術，那就更難以設計出安全的系統。

---

掃描如下二維碼便可關注訂閱號。