原創文章，轉載請註明：轉載自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的金鑰長度則可以從128、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金鑰交換的步驟如下：
Alice 向 Bob 傳送兩個質數 P 和 G
P 必須是一個非常大的質數，而 G 則是一個和 P 相關的數，稱為生成元(generator)。G 可以是一個較小的數字。
Alice 生成一個隨機數 A
A 是一個 1 ~ P-2 之間的整數。這個數是一個只有 Alice 知道的祕密數字。
Bob 生成一個隨機數 B
B 也是一個 1 ~ P-2 之間的整數。這個數是一個只有 Bob 才知道的祕密數字。
Alice 將 G^A mod P 計算結果的數傳送給 Bob
Bob 將 G^B mod P 計算結果的數傳送給 Alice
Alice 用 Bob 發過來的數計算 A 次方並求 mod P
這個數就是共享金鑰。Alice 計算的金鑰 = (G^B mod P)^A mod P = G^(A*B) mod P
Bob 用 Alice 發過來的數計算 B 次方並求 mod P
Bob 計算的金鑰 = (G^A mod P)^B mod P = G^(A*B) mod P = Alice 計算的金鑰。可見兩方計算的金鑰是相等的。
關於第1步提到的生成元是什麼呢？先來看一張表，假設 P = 13：
其中，2、6、7、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 的加密可以用下圖來表示：
主要有三個步驟：
生成 KEK
首先，通過偽隨機數生成器生成一個被稱為鹽(salt)的隨機數。然後，將鹽和口令一起輸入單向雜湊函式，輸出的結果就是 KEK。鹽是一種用於防禦字典攻擊的機制。
生成會話金鑰並加密
會話金鑰 CEK 也是通過偽隨機數生成器來生成，生成之後使用 KEK 對其進行加密，然後將加密後的會話金鑰和鹽一起儲存在安全的地方。
加密訊息
最後，使用 CEK 對訊息進行加密。
而 PBE 解密的過程則如下圖：
解密主要也是有三個步驟：
重建KEK
將之前儲存下來的鹽和口令一起輸入單向雜湊函式，得到的雜湊值就是 KEK 了。
解密會話金鑰
再將之前儲存下來的已加密的會話金鑰用 KEK 進行解密，就能得到會話金鑰 CEK 了。
解密訊息
最後，用已解密的 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各子協議都很簡單。密碼規格變更協議用於密碼切換的同步。簡單地說，就跟向對方喊“1、2、3！”差不多。當協議中途發生錯誤時，就會通過警告協議傳達給對方。警告協議負責在發生錯誤時將錯誤傳達給對方。如果沒有發生錯誤，則會使用應用資料協議來進行通訊。應用資料協議用於和通訊物件之間傳送應用資料。當TLS套接在HTTP時，HTTP的請求和相應就會通過TLS的應用資料協議和TLS記錄協議來進行傳送。
密碼技術與現實社會
前面講到的6種基本的密碼技術可整理成下圖：
書中多次使用了框架這個說法。框架的特點就是能夠對其中作為組成元素的技術進行替換，就像更好零件一樣。例如，訊息認證碼演算法HMAC的設計就允許對單向雜湊函式的演算法進行替換。在PGP中，對稱密碼、公鑰密碼、單向雜湊函式等都是可以替換的。在SSL/TLS中，客戶端和伺服器可以通過握手協議進行通訊，並當場決定所使用的密碼套件。使用框架能夠提高密碼技術系統的重用性，也能夠提高系統的強度。通過將單獨的密碼技術像零件一樣組合起來，並根據需要進行替換，能夠實現更長期的、更高的安全性。
另外，所有密碼技術其實也可以看成是一種“壓縮技術”，如下表所示：
量子密碼和量子計算機
量子密碼是基於量子理論的通訊技術，是一種讓通訊本身不可竊聽的技術，也可以理解為是一種利用光子的量子特性來實現通訊的方法。最早的量子密碼中，利用了兩個事實：
1. 從原理上說，無法準確測出光子的偏振方向
根據這一事實，可以讓竊聽者得到的內容變得不正確。複製程式碼2. 測量行為本身會導致光子的狀態傳送改變
根據這一事實，接收者可以判斷出通訊是否被竊聽。複製程式碼而量子計算機則有著超強的計算能力。如果有了量子計算機，那現有的所有密碼都能夠瞬間被暴力破解。根據量子理論，粒子可同時具有多種狀態。如果使用具有多種狀態的粒子進行計算，則可以同時完成多種狀態的計算。如果用1個粒子能夠計算0和1兩種狀態，那麼用128個這樣的粒子就可以同時計算2^128中狀態。換句話說，就是一臺超級平行計算機。
如果量子密碼比量子計算機先進入實用領域，則可以使用量子密碼來實現一次性密碼本，從而產生完美的密碼技術。由於一次性密碼本在原理上是無法破譯的，因此即使用量子計算機也無法破譯量子密碼。然而，如果量子計算機比量子密碼先進入實用領域，則實用目前的密碼技術所產生的密文將會全部被破譯。
只有完美的密碼，沒有完美的人
就算量子密碼進入實用領域，也不能實現完美的安全。因為在安全問題中，密碼技術能夠覆蓋的範圍是非常有限的。在確保系統的整體安全方面，人是一個特別巨大的弱點。
為了配送對稱密碼的金鑰，我們需要使用公鑰密碼，而為了對公鑰進行認證，我們又需要認證機構的公鑰。以此類推，無窮無盡，我們必須在某個節點上找到一個公鑰是自己能夠完全信任的，也就是必須要有一個信任的種子。
通過密碼技術，我們可以提高機密性，也能夠讓認證變得更加容易，但是這並不意味著我們可以實現完美的機密性和完美的認證。
就算通過人的指紋、聲紋、面容識別等生物識別認證也並不是完美的認證。要進行生物識別認證，就必須在某個時間點上將生物資訊轉換為位元序列，而實際的認證則是通過轉換後的位元序列來完成的。因此，如果這些位元序列被竊取，就會和鑰匙被偷產生相同的後果。
另外，“防禦必須天衣無縫，攻擊只需突破一點”。為了保衛系統安全，我們必須應對各種可能的攻擊，而且這種防禦必須24小時連續工作。另一方面，要攻擊一個系統，則只要找到一種有效的攻擊方法，而且只需利用防禦方一瞬間的破綻就可以完成了。
寫在最後
其實，在實際應用中，安全問題所涉及的技術，遠比這本書裡所講到的密碼技術多得多，也複雜得多。例如，App的加殼保護、OAuth認證等。在實際的應用中，還需要考慮更多，比如，安全性和效能之間需要平衡。雖然，懂得了這些密碼技術，並不意味著就能設計出非常安全的系統。但是，如果不懂這些密碼技術，那就更難以設計出安全的系統。
掃描以下二維碼即可關注訂閱號。
