密碼學與安全技術
工程領域從來沒有黑科技；密碼學不僅是工程。
密碼學相關的安全技術在整個信息技術領域的重要地位無需多言。如果沒有現代密碼學和信息安全的研究成果，人類社會根本無法進入信息時代。區塊鏈技術大量依賴了密碼學和安全技術的研究成果。
實際上，密碼學和安全領域所涉及的知識體系十分繁雜，本章將介紹密碼學領域中跟區塊鏈相關的一些基礎知識，包括Hash算法與數字摘要、加密算法、數字簽名、數字證書、PKI體系、Merkle樹、布隆過濾器、同態加密等。讀者通過閱讀本章可以瞭解如何使用這些技術保護信息的機密性、完整性、認證性和不可抵賴性。
一、Hash算法與數字摘要
1.1、Hash定義
Hash（哈希或散列）算法是非常基礎也非常重要的計算機算法，它能將任意長度的二進制明文串映射爲較短的（通常是固定長度的）二進制串（Hash值），並且不同的明文很難映射爲相同的Hash值。
例如計算一段話“hello blockchain world，this is yeasy@github”的SHA-256 Hash值。
$ echo “hello blockchain world, this is yeasy@github”|shasum -a 256
db8305d71a9f2f90a3e118a9b49a4c381d2b80cf7bcef81930f30ab1832a3c90
1
2
3
這意味着對於某個文件，無需查看其內容，只要其SHA-256 Hash計算後結果同樣爲db8305d71a9f2f90a3e118a9b49a4c381d2b80cf7bcef81930f30ab1832a3c90，則說明文件內容極大概率上就是“hello blockchain world，this is yeasy@github”。
Hash值在應用中又常被稱爲指紋（fingerprint）或摘要（digest）。Hash算法的核心思想也經常被應用到基於內容的編址或命名算法中。
一個優秀的Hash算法將能實現如下功能：
正向快速：給定明文和Hash算法，在有限時間和有限資源內能計算得到Hash值；
逆向困難：給定（若干）Hash值，在有限時間內很難（基本不可能）逆推出明文；
輸入敏感：原始輸入信息發生任何改變，新產生的Hash值都應該出現很大不同；
衝突避免：很難找到兩段內容不同的明文，使得它們的Hash值一致（發生碰撞）。
衝突避免有時候又稱爲“抗碰撞性”，分爲“弱抗碰撞性”和“強抗碰撞性”。如果給定明文前提下，無法找到與之碰撞的其他明文，則算法具有“弱抗碰撞性”；如果無法找到任意兩個發生Hash碰撞的明文，則稱算法具有“強抗碰撞性”。
很多場景下，也往往要求算法對於任意長的輸入內容，可以輸出定長的Hash值結果。
1.2、常見算法
目前常見的Hash算法包括MD5和SHA系列算法。
MD4（RFC 1320）是MIT的Ronald L.Rivest在1990年設計的，MD是Message Digest的縮寫。其輸出爲128位。MD4已被證明不夠安全。
MD5（RFC 1321）是Rivest於1991年對MD4的改進版本。它對輸入仍以512位進行分組，其輸出是128位。MD5比MD4更加安全，但過程更加複雜，計算速度要慢一點。MD5已被證明不具備“強抗碰撞性”。
SHA（Secure Hash Algorithm）並非一個算法，而是一個Hash函數族。NIST（National Institute of Standards and Technology）於1993年發佈其首個實現。目前知名的SHA-1算法在1995年面世，它的輸出爲長度160位的Hash值，抗窮舉性更好。SHA-1設計時模仿了MD4算法，採用了類似原理。SHA-1已被證明不具備“強抗碰撞性”。
爲了提高安全性，NIST還設計出了SHA-224、SHA-256、SHA-384和SHA-512算法（統稱爲SHA-2），跟SHA-1算法原理類似。SHA-3相關算法也已被提出。
目前，MD5和SHA1已經被破解，一般推薦至少使用SHA2-256或更安全的算法。
提示：MD5是一個經典的Hash算法，和SHA-1算法一起都被認爲安全性已不足應用於商業場景。
1.3、性能
Hash算法一般都是計算敏感型的。意味着計算資源是瓶頸，主頻越高的CPU運行Hash算法的速度也越快。因此可以通過硬件加速來提升Hash計算的吞吐量。例如採用FPGA來計算MD5值，可以輕易達到數十Gbps的吞吐量。
也有一些Hash算法不是計算敏感型的。例如scrypt算法，計算過程需要大量的內存資源，節點不能通過簡單地增加更多CPU來獲得Hash性能的提升。這樣的Hash算法經常用在避免算力攻擊的場景。
1.4、數字摘要
顧名思義，數字摘要是對數字內容進行Hash運算，獲取唯一的摘要值來指代原始完整的數字內容。數字摘要是Hash算法最重要的一個用途。利用Hash函數的抗碰撞性特點，數字摘要可以解決確保內容未被篡改過的問題。
細心的讀者可能會注意到，從網站下載軟件或文件時，有時會提供一個相應的數字摘要值。用戶下載原始文件後可以在本地自行計算摘要值，並與提供的摘要值進行比對，可檢查文件內容是否被篡改過。
1.5、Hash攻擊與防護
Hash算法並不是一種加密算法，不能用於對信息的保護。但Hash算法常用於對口令的保存上。例如用戶登錄網站需要通過用戶名和密碼來進行驗證。如果網站後臺直接保存用戶的口令明文，一旦數據庫發生泄露後果不堪設想。大量用戶傾向於在多個網站選用相同或關聯的口令。
利用Hash的特性，後臺可以僅保存口令的Hash值，這樣每次比對Hash值一致，則說明輸入的口令正確。即便數據庫泄露了，也無法從Hash值還原回口令，只有進行窮舉測試。
然而，由於有時用戶設置口令的強度不夠，只是一些常見的簡單字符串，如password、123456等。有人專門蒐集了這些常見口令，計算對應的Hash值，製作成字典。這樣通過Hash值可以快速反查到原始口令。這一類型以空間換時間的攻擊方法包括字典攻擊和彩虹表攻擊（只保存一條Hash鏈的首尾值，相對字典攻擊可以節省存儲空間）等。
爲了防範這一類攻擊，一般採用加鹽（salt）的方法。保存的不是口令明文的Hash值，而是口令明文再加上一段隨機字符串（即“鹽”）之後的Hash值。Hash結果和“鹽”分別存放在不同的地方，這樣只要不是兩者同時泄露，攻擊者就很難破解了。
二、加密算法
加解密算法是密碼學的核心技術，從設計理念上可以分爲兩大基本類型，如表5-1所示。
表5-1 加解密算法的類型
2.1、加解密系統基本組成
現代加解密系統的典型組件一般包括：加解密算法、加密密鑰、解密密鑰。其中，加解密算法自身是固定不變的，並且一般是公開可見的；密鑰則是最關鍵的信息，需要安全地保存起來，甚至通過特殊硬件進行保護。一般來說，對同一種算法，密鑰需要按照特定算法每次加密前隨機生成，長度越長，則加密強度越大。加解密的基本過程如圖5-1所示。
圖5-1 加解密的基本過程
加密過程中，通過加密算法和加密密鑰，對明文進行加密，獲得密文。
解密過程中，通過解密算法和解密密鑰，對密文進行解密，獲得明文。
根據加解密過程中所使用的密鑰是否相同，算法可以分爲對稱加密（symmetric cryptography，又稱公共密鑰加密，common-key cryptography）和非對稱加密（asymmetric cryptography，又稱公鑰加密，public-key cryptography）。兩種模式適用於不同的需求，恰好形成互補。某些時候可以組合使用，形成混合加密機制。
並非所有加密算法的安全性都可以從數學上得到證明。公認的高強度的加密算法和實現往往經過長時間各方面充分實踐論證後，才被大家所認可，但也不代表其絕對不存在漏洞。因此，自行設計和發明未經過大規模驗證的加密算法是一種不太明智的行爲。即便不公開算法加密過程，也很容易被攻破，無法在安全性上得到保障。
實際上，密碼學實現的安全往往是通過算法所依賴的數學問題來提供，而並非通過對算法的實現過程進行保密。
2.2、對稱加密算法
對稱加密算法，顧名思義，加密和解密過程的密鑰是相同的。該類算法優點是加解密效率（速度快，空間佔用小）和加密強度都很高。缺點是參與方都需要提前持有密鑰，一旦有人泄露則安全性被破壞；另外如何在不安全通道中提前分發密鑰也是個問題，需要藉助Diffie–Hellman協議或非對稱加密方式來實現。
對稱密碼從實現原理上可以分爲兩種：分組密碼和序列密碼。前者將明文切分爲定長數據塊作爲基本加密單位，應用最爲廣泛。後者則每次只對一個字節或字符進行加密處理，且密碼不斷變化，只用在一些特定領域，如數字媒介的加密等。
分組對稱加密代表算法包括DES、3DES、AES、IDEA等：
DES（Data Encryption Standard）：經典的分組加密算法，1977年由美國聯邦信息處理標準（FIPS）採用FIPS-46-3，將64位明文加密爲64位的密文，其密鑰長度爲64位（包含8位校驗位）。現在已經很容易被暴力破解；詳見http://blog.csdn.net/zyhlwzy/article/details/77948137
3DES：三重DES操作：加密→解密→加密，處理過程和加密強度優於DES，但現在也被認爲不夠安全；
AES（Advanced Encryption Standard）：由美國國家標準研究所（NIST）採用，取代DES成爲對稱加密實現的標準，1997～2000年NIST從15個候選算法中評選Rijndael算法（由比利時密碼學家Joan Daemon和Vincent Rijmen發明）作爲AES，標準爲FIPS-197。AES也是分組算法，分組長度爲128、192、256位三種。AES的優勢在於處理速度快，整個過程可以用數學描述，目前尚未有有效的破解手段；詳見http://blog.csdn.net/zyhlwzy/article/details/77948165
IDEA（International Data Encryption Algorithm）：1991年由密碼學家James Massey與來學嘉聯合提出。設計類似於3DES，密鑰長度增加到128位，具有更好的加密強度。
序列密碼，又稱流密碼。1949年，Claude Elwood Shannon（信息論創始人）首次證明，要實現絕對安全的完善保密性（perfect secrecy），可以通過“一次性密碼本”的對稱加密處理。即通信雙方每次使用跟明文等長的隨機密鑰串對明文進行加密處理。序列密碼採用了類似的思想，每次通過僞隨機數生成器來生成僞隨機密鑰串。代表算法包括RC4等。
對稱加密算法適用於大量數據的加解密過程；不能用於簽名場景；並且往往需要提前分發好密鑰。
注意：分組加密每次只能處理固定長度的明文，因此對於過長的內容需要採用一定模式進行分割處理，《實用密碼學》一書中推薦使用密文分組鏈（Cipher Block Chain，CBC）、計數器（Counter，CTR）等模式。
2.3、非對稱加密算法
非對稱加密是現代密碼學歷史上一項偉大的發明，可以很好地解決對稱加密中提前分發密鑰的問題。
顧名思義，非對稱加密算法中，加密密鑰和解密密鑰是不同的，分別稱爲公鑰（public key）和私鑰（private key）。私鑰一般需要通過隨機數算法生成，公鑰可以根據私鑰生成。公鑰一般是公開的，他人可獲取的；私鑰一般是個人持有，他人不能獲取。
非對稱加密算法的優點是公私鑰分開，不安全通道也可使用。缺點是處理速度（特別是生成密鑰和解密過程）往往比較慢，一般比對稱加解密算法慢2～3個數量級；同時加密強度也往往不如對稱加密算法。
非對稱加密算法的安全性往往需要基於數學問題來保障，目前主要有基於大數質因子分解、離散對數、橢圓曲線等經典數學難題進行保護。
代表算法包括：RSA、ElGamal、橢圓曲線（Elliptic Curve Crytosystems，ECC）、SM2等系列算法。
RSA：經典的公鑰算法，1978年由Ron Rivest、Adi Shamir、Leonard Adleman共同提出，三人於2002年因此獲得圖靈獎。算法利用了對大數進行質因子分解困難的特性，但目前還沒有數學證明兩者難度等價，或許存在未知算法在不進行大數分解的前提下解密；詳見：http://blog.csdn.net/zyhlwzy/article/details/77948195
Diffie-Hellman密鑰交換：基於離散對數無法快速求解，可以在不安全的通道上，雙方協商一個公共密鑰；
ElGamal：由Taher ElGamal設計，利用了模運算下求離散對數困難的特性。被應用在PGP等安全工具中；
橢圓曲線算法（Elliptic Curve Cryptography，ECC）：現代備受關注的算法系列，基於對橢圓曲線上特定點進行特殊乘法逆運算難以計算的特性。最早在1985年由Neal Koblitz和Victor Miller分別獨立提出。ECC系列算法一般被認爲具備較高的安全性，但加解密計算過程往往比較費時；
SM2（ShangMi 2）：國家商用密碼算法，由國家密碼管理局於2010年12月17日發佈，同樣基於橢圓曲線算法，加密強度優於RSA系列算法。
非對稱加密算法一般適用於簽名場景或密鑰協商，但不適於大量數據的加解密。
目前普遍認爲RSA類算法可能在不遠的將來被破解，一般推薦可採用安全強度更高的橢圓曲線系列算法。
2.4、選擇明文攻擊
細心的讀者可能會意識到，在非對稱加密中，由於公鑰是公開可以獲取的，因此任何人都可以給定明文，獲取對應的密文，這就帶來選擇明文攻擊的風險。
爲了規避這種風險，現有的非對稱加密算法（如RSA、ECC）都引入了一定的保護機制。對同樣的明文使用同樣密鑰進行多次加密，得到的結果完全不同，這就避免了選擇明文攻擊的破壞。
在實現上可以有多種思路。一種是對明文先進行變形，添加隨機的字符串或標記，再對添加後結果進行處理。另外一種是先用隨機生成的臨時密鑰對明文進行對稱加密，然後再對對稱密鑰進行加密，即混合利用多種加密機制。
2.5、混合加密機制
混合加密機制同時結合了對稱加密和非對稱加密的優點。
先用計算複雜度高的非對稱加密協商出一個臨時的對稱加密密鑰（也稱爲會話密鑰，一般相對所加密內容來說要短得多），然後雙方再通過對稱加密算法對傳遞的大量數據進行快速的加解密處理。
典型的應用案例是現在大家常用的HTTPS協議。HTTPS協議正在替換掉傳統的不安全的HTTP協議，成爲最普遍的Web通信協議。
HTTPS在傳統的HTTP層和TCP層之間通過引入Transport Layer Security/Secure Socket Layer（TLS/SSL）加密層來實現可靠的傳輸。
SSL協議最早是Netscape於1994年設計出來實現早期HTTPS的方案，SSL 3.0及之前版本存在漏洞，被認爲不夠安全。TLS協議是IETF基於SSL協議提出的安全標準，目前最新的版本爲1.2（2008年發佈）。推薦使用的版本號至少爲TLS 1.0，對應到SSL 3.1版本。除了Web服務外，TLS協議也廣泛應用於Email、實時消息、音視頻通話等領域。
採用HTTPS建立安全連接（TLS握手協商過程）的基本步驟如下（可參見圖5-2）：
圖5-2 TLS握手協商過程
客戶端瀏覽器發送信息到服務器，包括隨機數R1、支持的加密算法類型、協議版本、壓縮算法等。注意該過程爲明文。
服務端返回信息，包括隨機數R2、選定加密算法類型、協議版本以及服務器證書。注意該過程爲明文。
瀏覽器檢查帶有該網站公鑰的證書。該證書需要由第三方CA來簽發，瀏覽器和操作系統會預置權威CA的根證書。如果證書被篡改作假（中間人攻擊），很容易通過CA的證書驗證出來。
如果證書沒問題，則客戶端用服務端證書中的公鑰加密隨機數R3（又叫Pre-MasterSecret），發送給服務器。此時，只有客戶端和服務器都擁有R1、R2和R3信息，基於隨機數R1、R2和R3，雙方通過僞隨機數函數來生成共同的對稱會話密鑰MasterSecret。
後續客戶端和服務端的通信都通過對稱加密算法（如AES）進行保護。
可以看出，該過程的主要功能是在防止中間人竊聽和篡改的前提下完成會話密鑰的協商。爲了保障前向安全性（perfect forward secrecy），TLS對每個會話連接都可以生成不同的密鑰，避免某次會話密鑰泄露之後影響了其他會話連接的安全性。需要注意，TLS協商過程支持加密算法方案較多，要合理地選擇安全強度高的算法，如DHE-RSA、ECDHE-RSA和ECDHE-ECDSA。
示例中對稱密鑰的協商過程採用了RSA非對稱加密算法，實踐中也可以通過Diffie–Hellman協議來完成。
2.6、離散對數與Diffie–Hellman密鑰交換協議
Diffie–Hellman（DH）密鑰交換協議是一個經典的協議，最早發表於1976年，應用十分廣泛。使用該協議可以在不安全信道完成對稱密鑰的協商，以便後續通信採用對稱加密。
DH協議的設計基於離散對數問題（Discrete Logarithm Problem，DLP）。離散對數問題是指對於一個很大的素數p，已知g爲p的模循環羣的原根，給定任意x，求解X=g^x mod p是可以很快獲取的。但在已知p、g和X的前提下，逆向求解x目前沒有多項式時間實現的算法。該問題同時也是ECC類加密算法的基礎。
DH協議的基本交換過程如下：
Alice和Bob兩個人協商密鑰，先公開商定p，g；
Alice自行選取私密的整數x，計算X=g^x mod p，發送X給Bob；
Bob自行選取私密的整數y，計算Y=g^y mod p，發送Y給A；
Alice根據x和Y，求解共同密鑰Z_A=Y^x mod p；
Bob根據X和y，求解共同密鑰Z_B=X^y mod p。
實際上，Alice和Bob計算出來的結果將完全相同，因爲在mod p的前提下，Yx=（gy）x=g（xy）=（gx）y=X^y。而信道監聽者在已知p、g、X、Y的前提下，無法求得Z。
三、消息認證碼與數字簽名
消息認證碼和數字簽名技術通過對消息的摘要進行加密，可用於消息防篡改和身份證明問題。
3.1、消息認證碼
消息認證碼全稱是“基於Hash的消息認證碼”（Hash-based Message Authentication Code，HMAC）。消息驗證碼基於對稱加密，可以用於對消息完整性（integrity）進行保護。
基本過程爲：對某個消息利用提前共享的對稱密鑰和Hash算法進行加密處理，得到HMAC值。該HMAC值持有方可以證明自己擁有共享的對稱密鑰，並且也可以利用HMAC確保消息內容未被篡改。
典型的HMAC（K，H，Message）算法包括三個因素，K爲提前共享的對稱密鑰，H爲提前商定的Hash算法（一般爲公認的經典算法如SHA-256），Message爲要處理的消息內容。如果不知道K或H的任何一個，則無法根據Message得到正確的HMAC值。
消息認證碼一般用於證明身份的場景。如Alice、Bob提前共享和HMCA的密鑰和Hash算法，Alice需要知曉對方是否爲Bob，可發送隨機消息給Bob。Bob收到消息後進行計算，把消息HMAC值返回給Alice，Alice通過檢驗收到HMAC值的正確性可以知曉對方是否是Bob。注意這裏並沒有考慮中間人攻擊的情況，假定信道是安全的。
消息認證碼使用過程中主要問題是需要共享密鑰。當密鑰可能被多方擁有的場景下，無法證明消息來自某個確切的身份。反之，如果採用非對稱加密方式，則可以追溯到來源身份，即數字簽名。
3.2、數字簽名
與在紙質合同上簽名確認合同內容和證明身份類似，數字簽名基於非對稱加密，既可以用於證實某數字內容的完整性，又同時可以確認來源（或不可抵賴，Non-Repudiation）。
一個典型的場景是，Alice通過信道發給Bob一個文件（一份信息），Bob如何獲知所收到的文件即爲Alice發出的原始版本？Alice可以先對文件內容進行摘要，然後用自己的私鑰對摘要進行加密（簽名），之後同時將文件和簽名都發給Bob。Bob收到文件和簽名後，用Alice的公鑰來解密簽名，得到數字摘要，與收到文件進行摘要後的結果進行比對。如果一致，說明該文件確實是Alice發過來的（別人無法擁有Alice的私鑰），並且文件內容沒有被修改過（摘要結果一致）。
知名的數字簽名算法包括DSA（Digital Signature Algorithm）和安全強度更高的ECSDA（Elliptic Curve Digital Signature Algorithm）等。
除普通的數字簽名應用場景外，針對一些特定的安全需求，產生了一些特殊數字簽名技術，包括盲簽名、多重簽名、羣簽名、環簽名等。
3.2.1、盲簽名
盲簽名（blind signature）是在1982年由David Chaum在論文《Blind Signatures for Untraceable Payment》中提出。簽名者需要在無法看到原始內容的前提下對信息進行簽名。
盲簽名可以實現對所簽名內容的保護，防止簽名者看到原始內容；另一方面，盲簽名還可以實現防止追蹤（unlinkability），簽名者無法將簽名內容和簽名結果進行對應。典型的實現包括RSA盲簽名算法等。
3.2.2、多重簽名
多重簽名（multiple signature）即n個簽名者中，收集到至少m個（n>=m>=1）的簽名，即認爲合法。其中，n是提供的公鑰個數，m是需要匹配公鑰的最少的簽名個數。
多重簽名可以有效地被應用在多人投票共同決策的場景中。例如雙方進行協商，第三方作爲審覈方。三方中任何兩方達成一致即可完成協商。
比特幣交易中就支持多重簽名，可以實現多個人共同管理某個賬戶的比特幣交易。
3.2.3、羣簽名
羣簽名（group signature）即某個羣組內一個成員可以代表羣組進行匿名簽名。簽名可以驗證來自於該羣組，卻無法準確追蹤到簽名的是哪個成員。
羣簽名需要存在一個羣管理員來添加新的羣成員，因此存在羣管理員可能追蹤到簽名成員身份的風險。
羣簽名最早於1991年由David Chaum和Eugene van Heyst提出。
3.2.4、環簽名
環簽名（ring signature），由Rivest、Shamir和Tauman三位密碼學家在2001年首次提出。環簽名屬於一種簡化的羣簽名。
簽名者首先選定一個臨時的簽名者集合，集合中包括簽名者自身。然後簽名者利用自己的私鑰和簽名集合中其他人的公鑰就可以獨立地產生簽名，而無需他人的幫助。簽名者集合中的其他成員可能並不知道自己被包含在最終的簽名中。
環簽名在保護匿名性方面有很多的用途。
3.3、安全性
數字簽名算法自身的安全性由數學問題進行保障，但在使用上，系統的安全性也十分關鍵。目前常見的數字簽名算法往往需要選取合適的隨機數作爲配置參數，配置參數不合理的使用或泄露都會造成安全漏洞，需要進行安全保護。
2010年，SONY公司因爲其PS3產品上採用安全的ECDSA進行簽名時，不慎採用了重複的隨機參數，導致私鑰被最終破解，造成重大經濟損失。
四、數字證書
對於非對稱加密算法和數字簽名來說，很重要的一點就是公鑰的分發。理論上任何人可以公開獲取到對方的公鑰。然而這個公鑰有沒有可能是僞造的呢？傳輸過程中有沒有可能被篡改掉呢？一旦公鑰自身出了問題，則整個建立在其上的安全體系的安全性將不復存在。
數字證書機制正是爲了解決這個問題，它就像日常生活中的一個證書一樣，可以證明所記錄信息的合法性。比如證明某個公鑰是某個實體（如組織或個人）的，並且確保一旦內容被篡改能被探測出來，從而實現對用戶公鑰的安全分發。
根據所保護公鑰的用途，可以分爲加密數字證書（Encryption Certificate）和簽名驗證數字證書（Signature Certificate）。前者往往用於保護用於加密信息的公鑰；後者則保護用於進行解密簽名進行身份驗證的公鑰。兩種類型的公鑰也可以同時放在同一證書中。
一般情況下，證書需要由證書認證機構（Certification Authority，CA）來進行簽發和背書。權威的證書認證機構包括DigiCert、GlobalSign、VeriSign等。用戶也可以自行搭建本地CA系統，在私有網絡中進行使用。
4.1、X.509證書規範
一般來說，一個數字證書內容可能包括基本數據（版本、序列號）、所簽名對象信息（簽名算法類型、簽發者信息、有效期、被簽發人、簽發的公開密鑰）、CA的數字簽名，等等。
目前使用最廣泛的標準爲ITU和ISO聯合制定的X.509的v3版本規範（RFC 5280），其中定義瞭如下證書信息域：
版本號（Version Number）：規範的版本號，目前爲版本3，值爲0x2；
序列號（Serial Number）：由CA維護的爲它所頒發的每個證書分配的唯一的序列號，用來追蹤和撤銷證書。只要擁有簽發者信息和序列號，就可以唯一標識一個證書，最大不能超過20個字節；
簽名算法（Signature Algorithm）：數字簽名所採用的算法，如sha256WithRSAEncryption或ecdsa-with-SHA256；
頒發者（Issuer）：頒發證書單位的標識信息，如“C=CN，ST=Beijing，L=Beijing，O=org.example.com，CN=ca.org.example.com”；
有效期（Validity）：證書的有效期限，包括起止時間；
主體（Subject）：證書擁有者的標識信息（Distinguished Name），如“C=CN，ST=Beijing，L=Beijing，CN=person.org.example.com”；
主體的公鑰信息（Subject Public Key Info）：所保護的公鑰相關的信息；
公鑰算法（Public Key Algorithm）：公鑰採用的算法；
主體公鑰（Subject Public Key）：公鑰的內容；
頒發者唯一號（Issuer Unique Identifier）：代表頒發者的唯一信息，僅2、3版本支持，可選；
主體唯一號（Subject Unique Identifier）：代表擁有證書實體的唯一信息，僅2、3版本支持，可選；
擴展（Extensions，可選）：可選的一些擴展。v3中可能包括：
Subject Key Identifier：實體的密鑰標識符，區分實體的多對密鑰；
Basic Constraints：一般指明是否屬於CA；
Authority Key Identifier：證書頒發者的公鑰標識符；
CRL Distribution Points：撤銷文件的發佈地址；
Key Usage：證書的用途或功能信息。
此外，證書的頒發者還需要對證書內容利用自己的公鑰添加簽名，以防止別人對證書內容進行篡改。
4.2、證書格式
X.509規範中一般推薦使用PEM（Privacy Enhanced Mail）格式來存儲證書相關的文件。證書文件的文件名後綴一般爲.crt或.cer，對應私鑰文件的文件名後綴一般爲.key，證書請求文件的文件名後綴爲.csr。有時候也統一用.pem作爲文件名後綴。
PEM格式採用文本方式進行存儲，一般包括首尾標記和內容塊，內容塊採用Base64進行編碼。
例如，一個PEM格式的示例證書文件如下所示：
-----BEGIN CERTIFICATE-----
MIICMzCCAdmgAwIBAgIQIhMiRzqkCljq3ZXnsl6EijAKBggqhkjOPQQDAjBmMQsw
CQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMNU2FuIEZy
YW5jaXNjbzEUMBIGA1UEChMLZXhhbXBsZS5jb20xFDASBgNVBAMTC2V4YW1wbGUu
Y29tMB4XDTE3MDQyNTAzMzAzN1oXDTI3MDQyMzAzMzAzN1owZjELMAkGA1UEBhMC
VVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28x
FDASBgNVBAoTC2V4YW1wbGUuY29tMRQwEgYDVQQDEwtleGFtcGxlLmNvbTBZMBMG
ByqGSM49AgEGCCqGSM49AwEHA0IABCkIHZ3mJCEPbIbUdh/Kz3zWW1C9wxnZOwfy
yrhr6aHwWREW3ZpMWKUcbsYup5kbouBc2dvMFUgoPBoaFYJ9D0SjaTBnMA4GA1Ud
DwEB/wQEAwIBpjAZBgNVHSUEEjAQBgRVHSUABggrBgEFBQcDATAPBgNVHRMBAf8E
BTADAQH/MCkGA1UdDgQiBCBIA/DmemwTGibbGe8uWjt5hnlE63SUsXuNKO9iGEhV
qDAKBggqhkjOPQQDAgNIADBFAiEAyoMO2BAQ3c9gBJOk1oSyXP70XRk4dTwXMF7q
R72ijLECIFKLANpgWFoMoo3W91uzJeUmnbJJt8Jlr00ByjurfAvv
-----END CERTIFICATE-----
1
2
3
4
5
6
7
8
9
10
11
12
13
14
可以通過OpenSSL工具來查看其內容：
openssl x509 -in example.com-cert.pem -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
22:13:22:47:3a:a4:0a:58:ea:dd:95:e7:b2:5e:84:8a
Signature Algorithm: ecdsa-with-SHA256
Issuer: C=US, ST=California, L=San Francisco, O=example.com,
CN=example.com
Validity
Not Before: Apr 25 03:30:37 2017 GMT
Not After : Apr 23 03:30:37 2027 GMT
Subject: C=US, ST=California, L=San Francisco, O=example.com,
CN=example.com
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:29:08:1d:9d:e6:24:21:0f:6c:86:d4:76:1f:ca:
cf:7c:d6:5b:50:bd:c3:19:d9:3b:07:f2:ca:b8:6b:
e9:a1:f0:59:11:16:dd:9a:4c:58:a5:1c:6e:c6:2e:
a7:99:1b:a2:e0:5c:d9:db:cc:15:48:28:3c:1a:1a:
15:82:7d:0f:44
ASN1 OID: prime256v1
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment, Certificate Sign,
CRL Sign
X509v3 Extended Key Usage:
Any Extended Key Usage, TLS Web Server Authentication
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Key Identifier:
48:03:F0:E6:7A:6C:13:1A:26:DB:19:EF:2E:5A:3B:79:86:
79:44:EB:74:94:B1:7B:8D:28:EF:62:18:48:55:A8
Signature Algorithm: ecdsa-with-SHA256
30:45:02:21:00:ca:83:0e:d8:10:10:dd:cf:60:04:93:a4:d6:
84:b2:5c:fe:f4:5d:19:38:75:3c:17:30:5e:ea:47:bd:a2:8c:
b1:02:20:52:8b:00:da:60:58:5a:0c:a2:8d:d6:f7:5b:b3:25:
e5:26:9d:b2:49:b7:c2:65:af:4d:01:ca:3b🆎7c:0b:ef
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
此外，還有DER（Distinguished Encoding Rules）格式，是採用二進制對證書進行保存，可以與PEM格式互相轉換。
4.3、證書信任鏈
證書中記錄了大量信息，其中最重要的包括“簽發的公開密鑰”和“CA數字簽名”兩個信息。因此，只要使用CA的公鑰再次對這個證書進行簽名比對，就能證明某個實體的公鑰是否是合法的。
讀者可能會想到，怎麼證明用來驗證對實體證書進行簽名的CA公鑰自身是否合法呢？畢竟在獲取CA公鑰的過程中，它也可能被篡改掉。
實際上，要想知道CA的公鑰是否合法，一方面可以通過更上層的CA頒發的證書來進行認證；另一方面某些根CA（Root CA）可以通過預先分發證書來實現信任基礎。例如，主流操作系統和瀏覽器裏面，往往會提前預置一些權威CA的證書（通過自身的私鑰簽名，系統承認這些是合法的證書）。之後所有基於這些CA認證過的中間層CA（Intermediate CA）和後繼CA都會被驗證合法。這樣就從預先信任的根證書，經過中間層證書，到最底下的實體證書，構成一條完整的證書信任鏈。
某些時候用戶在使用瀏覽器訪問某些網站時，可能會被提示是否信任對方的證書。這說明該網站證書無法被當前系統中的證書信任鏈進行驗證，需要進行額外檢查。另外，當信任鏈上任一證書不可靠時，則依賴它的所有後繼證書都將失去保障。
可見，證書作爲公鑰信任的基礎，對其生命週期進行安全管理十分關鍵。下節將介紹的PKI體系提供了一套完整的證書管理的框架，包括生成、頒發、撤銷過程等。
五、PKI體系
在非對稱加密中，公鑰可以通過證書機制來進行保護，但證書的生成、分發、撤銷等過程並沒有在X.509規範中進行定義。
實際上，安全地管理和分發證書可以遵循PKI（Public Key Infrastructure）體系來完成。PKI體系核心解決的是證書生命週期相關的認證和管理問題，在現代密碼學應用領域處於十分基礎和重要的地位。
需要注意，PKI是建立在公私鑰基礎上實現安全可靠傳遞消息和身份確認的一個通用框架，並不代表某個特定的密碼學技術和流程。實現了PKI規範的平臺可以安全可靠地管理網絡中用戶的密鑰和證書。目前包括多個實現和規範，知名的有RSA公司的PKCS（Public Key Cryptography Standards）標準和X.509相關規範等。
5.1、PKI基本組件
一般情況下，PKI至少包括如下核心組件：
CA（Certification Authority）：負責證書的頒發和作廢，接收來自RA的請求，是最核心的部分；
RA（Registration Authority）：對用戶身份進行驗證，校驗數據合法性，負責登記，審覈過了就發給CA；
證書數據庫：存放證書，多采用X.500系列標準格式。可以配合LDAP目錄服務管理用戶信息。
其中，CA是最核心的組件，主要完成對證書信息的維護。
常見的操作流程爲，用戶通過RA登記申請證書，提供身份和認證信息等；CA審覈後完成證書的製造，頒發給用戶。用戶如果需要撤銷證書則需要再次向CA發出申請。
5.2、證書的簽發
CA對用戶簽發證書實際上是對某個用戶公鑰，使用CA的私鑰對其進行簽名。這樣任何人都可以用CA的公鑰對該證書進行合法性驗證。驗證成功則認可該證書中所提供的用戶公鑰內容，實現用戶公鑰的安全分發。
用戶證書的簽發可以有兩種方式。一般可以由CA直接來生成證書（內含公鑰）和對應的私鑰發給用戶；也可以由用戶自己生成公鑰和私鑰，然後由CA來對公鑰內容進行簽名。
後者情況下，用戶一般會首先自行生成一個私鑰和證書申請文件（Certificate Signing Request，即csr文件），該文件中包括了用戶對應的公鑰和一些基本信息，如通用名（common name，即cn）、組織信息、地理位置等。CA只需要對證書請求文件進行簽名，生成證書文件，頒發給用戶即可。整個過程中，用戶可以保持私鑰信息的私密性，不會被其他方獲知（包括CA方）。
生成證書申請文件的過程並不複雜，用戶可以很容易地使用開源軟件openssl來生成csr文件和對應的私鑰文件。
例如，安裝OpenSSL後可以執行如下命令來生成私鑰和對應的證書請求文件：
$ openssl req -new -keyout private.key -out for_request.csr
Generating a 1024 bit RSA private key
…++++++
…++++++
writing new private key to ‘private.key’
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, the field will be left blank.
Country Name (2 letter code) [AU]:CN
State or Province Name (full name) [Some-State]:Beijing
Locality Name (eg, city) []:Beijing
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Blockchain
Organizational Unit Name (eg, section) []:Dev
Common Name (e.g. server FQDN or YOUR name) []:example.com
Email Address []:
Please enter the following ‘extra’ attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
生成過程中需要輸入地理位置、組織、通用名等信息。生成的私鑰和csr文件默認以PEM格式存儲，內容爲Base64編碼。
如生成的csr文件內容可能爲：
$ cat for_request.csr
1
-----BEGIN CERTIFICATE REQUEST-----
MIIBrzCCARgCAQAwbzELMAkGA1UEBhMCQ04xEDAOBgNVBAgTB0JlaWppbmcxEDAO
BgNVBAcTB0JlaWppbmcxEzARBgNVBAoTCkJsb2NrY2hhaW4xDDAKBgNVBAsTA0Rl
djEZMBcGA1UEAxMQeWVhc3kuZ2l0aHViLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOB
jQAwgYkCgYEA8fzVl7MJpFOuKRH+BWqJY0RPTQK4LB7fEgQFTIotO264ZlVJVbk8
Yfl42F7dh/8SgHqmGjPGZgDb3hhIJLoxSOI0vJweU9v6HiOVrFWE7BZEvhvEtP5k
lXXEzOewLvhLMNQpG0kBwdIh2EcwmlZKcTSITJmdulEvoZXr/DHXnyUCAwEAAaAA
MA0GCSqGSIb3DQEBBQUAA4GBAOtQDyJmfP64anQtRuEZPZji/7G2+y3LbqWLQIcj
IpZbexWJvORlyg+iEbIGno3Jcia7lKLih26lr04W/7DHn19J6Kb/CeXrjDHhKGLO
I7s4LuE+2YFSemzBVr4t/g24w9ZB4vKjN9X9i5hc6c6uQ45rNlQ8UK5nAByQ/TWD
OxyG
-----END CERTIFICATE REQUEST-----
1
2
3
4
5
6
7
8
9
10
11
12
13
14
openssl工具提供了查看PEM格式文件明文的功能，如使用如下命令可以查看生成的csr文件的明文：
$ openssl req -in for_request.csr -noout -text
Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=CN, ST=Beijing, L=Beijing, O=Blockchain, OU=Dev,
CN=yeasy.github.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:f1:fc:d5:97:b3:09:a4:53:ae:29:11:fe:05:6a:
89:63:44:4f:4d:02:b8:2c:1e:df:12:04:05:4c:8a:
2d:3b:6e:b8:66:55:49:55:b9:3c:61:f9:78:d8:5e:
dd:87:ff:12:80:7a:a6:1a:33:c6:66:00:db🇩🇪18:
48:24:ba:31:48:e2:34:bc:9c:1e:53:db:fa:1e:23:
95:ac:55:84:ec:16:44:be:1b:c4:b4:fe:64:95:75:
c4:cc:e7:b0:2e:f8:4b:30:d4:29:1b:49:01:c1:d2:
21:d8:47:30:9a:56:4a:71:34:88:4c:99:9d:ba:51:
2f:a1:95:eb:fc:31:d7:9f:25
Exponent: 65537 (0x10001)
Attributes:
a0:00
Signature Algorithm: sha1WithRSAEncryption
eb:50:0f:22:66:7c:fe:b8:6a:74:2d:46:e1:19:3d:98:e2:ff:
b1:b6:fb:2d:cb:6e:a5:8b:40:87:23:22:96:5b:7b:15:89:bc:
e4:65:ca:0f:a2:11:b2:06:9e:8d:c9:72:26:bb:94:a2:e2:87:
6e:a5:af:4e:16:ff:b0:c7:9f:5f:49:e8:a6:ff:09:e5:eb:8c:
31:e1:28:62:ce:23:bb:38:2e:e1:3e:d9:81:52:7a:6c:c1:56:
be:2d:fe:0d:b8:c3:d6:41:e2:f2:a3:37:d5:fd:8b:98:5c:e9:
ce:ae:43:8e:6b:36:54:3c:50:ae:67:00:1c:90:fd:35:83:3b:
1c:86
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
需要注意，用戶自行生成私鑰情況下，私鑰文件一旦丟失，CA方由於不持有私鑰信息，無法進行恢復，意味着通過該證書中公鑰加密的內容將無法被解密。
5.3、證書的撤銷
證書超出有效期後會作廢，用戶也可以主動向CA申請撤銷某證書文件。
由於CA無法強制收回已經頒發出去的數字證書，因此爲了實現證書的作廢，往往還需要維護一個撤銷證書列表（Certificate Revocation List，CRL），用於記錄已經撤銷的證書序號。
因此，通常情況下，當第三方對某個證書進行驗證時，需要首先檢查該證書是否在撤銷列表中。如果存在，則該證書無法通過驗證。如果不在，則繼續進行後續的證書驗證過程。
六、Merkle樹結構
Merkle（默克爾）樹，又叫哈希樹，是一種典型的二叉樹結構，由一個根節點、一組中間節點和一組葉節點組成。在區塊鏈系統出現之前，廣泛用於文件系統和P2P系統中，如圖5-3所示。
圖5-3 Merkle樹示例
其主要特點爲：
最下面的葉節點包含存儲數據或其哈希值；
非葉子節點（包括中間節點和根節點）都是它的兩個孩子節點內容的哈希值。
進一步地，默克爾樹可以推廣到多叉樹的情形，此時非葉子節點的內容爲它所有的孩子節點內容的哈希值。
默克爾樹逐層記錄哈希值的特點，讓它具有了一些獨特的性質。例如，底層數據的任何變動，都會傳遞到其父節點，一層層沿着路徑一直到樹根。這意味樹根的值實際上代表了對底層所有數據的“數字摘要”。
目前，默克爾樹的典型應用場景有很多，下面分別介紹。
6.1、快速比較大量數據
對每組數據排序後構建默克爾樹結構。當兩個默克爾樹根相同時，則意味着兩組數據必然相同。否則，必然存在不同。
由於Hash計算的過程可以十分快速，預處理可以在短時間內完成。利用默克爾樹結構能帶來巨大的比較性能優勢。
6.2、快速定位修改
例如圖5-3中，如果D1中數據被修改，會影響到N1、N4和Root。
因此，一旦發現某個節點如Root的數值發生變化，沿着Root→N4→N1，最多通過O（logn）時間即可快速定位到實際發生改變的數據塊D1。
6.3、零知識證明
仍以圖5-3爲例，如何向他人證明擁有的某組數據（D0……D3）中包括給定某個內容D0而不暴露其他任何內容。
很簡單，構造如圖所示的一個默克爾樹，公佈N1、N5、Root。D0擁有者通過驗證生成的Root是否跟提供的值一致，即可很容易檢測D0存在。整個過程中驗證者無法獲知其他內容。
七、布隆過濾器
布隆過濾器（Bloom Filter）於1970年由Burton Howard Bloom在論文《Space/Time Trade-offs in Hash Coding with Allowable Errors》中提出。布隆過濾器是一種基於Hash的高效查找結構，能夠快速（常數時間內）回答“某個元素是否在一個集合內”的問題。
布隆過濾器因爲其高效性大量應用於網絡和安全領域，例如信息檢索（BigTable和HBase）、垃圾郵件規則、註冊管理等。
7.1、基於Hash的快速查找
在布隆過濾器之前，先來看基於Hash的快速查找算法。在前面的講解中我們提到，Hash可以將任意內容映射到一個固定長度的字符串，而且不同內容映射到相同串的概率很低。因此，這就構成了一個很好的“內容→索引”的生成關係。
試想，如果給定一個內容和存儲數組，通過構造Hash函數，讓映射後的Hash值總不超過數組的大小，則可以實現快速的基於內容的查找。例如，內容“hello world”的Hash值如果是“100”，則存放到數組的第100個單元上去。如果需要快速查找任意內容，如“hello world”字符串是否在存儲系統中，只需要將其在常數時間內計算Hash值，並用Hash值查看系統中對應元素即可。該系統“完美地”實現了常數時間內的查找。
然而，令人遺憾的是，當映射後的值限制在一定範圍（如總數組的大小）內時，會發現Hash衝突的概率會變高，而且範圍越小，衝突概率越大。很多時候，存儲系統的大小又不能無限擴展，這就造成算法效率的下降。爲了提高空間利用率，後來人們基於Hash算法的思想設計出了布隆過濾器結構。
7.2、更高效的布隆過濾器
布隆過濾器採用了多個Hash函數來提高空間利用率。對同一個給定輸入來說，多個Hash函數計算出多個地址，分別在位串的這些地址上標記爲1。進行查找時，進行同樣的計算過程，並查看對應元素，如果都爲1，則說明較大概率是存在該輸入。如圖5-4所示。
圖5-4 布隆過濾器
布隆過濾器相對單個Hash算法查找，大大提高了空間利用率，可以使用較少的空間來表示較大集合的存在關係。
實際上，無論是Hash算法，還是布隆過濾器，基本思想是一致的，都是基於內容的編址。Hash函數存在衝突，布隆過濾器也存在衝突。這就造成了兩種方法都存在着誤報（false positive）的情況，但絕對不會漏報（false negative）。
布隆過濾器在應用中誤報率往往很低，例如，在使用7個不同Hash函數的情況下，記錄100萬個數據，採用2 MB大小的位串，整體的誤判率將低於1%。而傳統的Hash查找算法的誤報率將接近10%。
八、同態加密
8.1、定義
同態加密（homomorphic encryption）是一種特殊的加密方法，允許對密文進行處理得到仍然是加密的結果。即對密文直接進行處理，跟對明文進行處理後再對處理結果加密，得到的結果相同。從抽象代數的角度講，保持了同態性。
同態加密可以保證實現處理者無法訪問到數據自身的信息。
如果定義一個運算符Δ，對加密算法E和解密算法D，滿足：
E（XΔY）=E（X）ΔE（Y）
則意味着對於該運算滿足同態性。
同態性來自代數領域，一般包括四種類型：加法同態、乘法同態、減法同態和除法同態。同時滿足加法同態和乘法同態，則意味着是代數同態，稱爲全同態（full homomorphic）。同時滿足四種同態性，則稱爲算數同態。
對於計算機操作來講，實現了全同態意味着對於所有處理都可以實現同態性。只能實現部分特定操作的同態性，稱爲特定同態（somewhat homomorphic）。
8.2、問題與挑戰
同態加密的問題最早是由Ron Rivest、Leonard Adleman和Michael L.Dertouzos在1978年提出，同年提出了RSA加密算法。但第一個“全同態”的算法直到2009年才被克雷格·金特里（Craig Gentry）在論文《Fully Homomorphic Encryption Using Ideal Lattices》中提出並進行數學證明。
僅滿足加法同態的算法包括Paillier和Benaloh算法；僅滿足乘法同態的算法包括RSA和ElGamal算法。
同態加密在雲計算和大數據的時代意義十分重大。目前，雖然雲計算帶來了包括低成本、高性能和便捷性等優勢，但從安全角度講，用戶還不敢將敏感信息直接放到第三方雲上進行處理。如果有了比較實用的同態加密技術，則大家就可以放心地使用各種雲服務了，同時各種數據分析過程也不會泄露用戶隱私。加密後的數據在第三方服務處理後得到加密後的結果，這個結果只有用戶自身可以進行解密，整個過程第三方平臺無法獲知任何有效的數據信息。
另一方面，對於區塊鏈技術，同態加密也是很好的互補。使用同態加密技術，運行在區塊鏈上的智能合約可以處理密文，而無法獲知真實數據，極大地提高了隱私安全性。
目前全同態的加密方案主要包括如下三種類型：
基於理想格（ideal lattice）的方案：Gentry和Halevi在2011年提出的基於理想格的方案可以實現72 bit的安全強度，對應的公鑰大小約爲2.3 GB，同時刷新密文的處理時間需要幾十分鐘；
基於整數上近似GCD問題的方案：Dijk等人在2010年提出的方案（及後續方案）採用了更簡化的概念模型，可以降低公鑰大小至幾十MB量級；
基於帶擾動學習（Learning With Errors，LWE）問題的方案：Brakerski和Vaikuntanathan等在2011年左右提出了相關方案；Lopez-Alt A等在2012年設計出多密鑰全同態加密方案，接近實時多方安全計算的需求。
目前，已知的同態加密技術往往需要較高的計算時間或存儲成本，相比傳統加密算法的性能和強度還有差距，但該領域被關注度一直很高，筆者相信，在不遠的將來會出現接近實用的方案。
8.3、函數加密
與同態加密相關的一個問題是函數加密。
同態加密保護的是數據本身，而函數加密保護的是處理函數本身，即讓第三方看不到處理過程的前提下，對數據進行處理。
該問題已被證明不存在對多個通用函數的任意多密鑰的方案，目前僅能做到對某個特定函數的一個密鑰的方案。
九、其他問題
密碼學領域涉及的問題還有許多，這裏列出一些還在發展和探討中的相關技術。
9.1、零知識證明
零知識證明（zero knowledge proof）是這樣的一個過程，證明者在不向驗證者提供任何額外信息的前提下，使驗證者相信某個論斷是正確的。
例如，Alice向Bob證明自己知道某個數字，在證明過程中Bob可以按照某個順序提出問題（比如數字加上某些隨機數後的變換）由Alice回答，並通過回答確信Alice較大概率確實知道某數字。證明過程中，Bob除了知道Alice確實知道該數字外，自己無法獲知或推理出任何額外信息（包括該數字本身），也無法用Alice的證明去向別人證明（Alice如果提前猜測出Bob問題的順序，存在作假的可能性）。
零知識證明的研究始於1985年Shafi Goldwasser等人的論文《The Knowledge Complexity of Interactive Proof-Systems》，目前一般認爲至少要滿足三個條件：
完整性（Completeness）：真實的證明可以讓驗證者成功驗證；
可靠性（Soundness）：虛假的證明無法讓驗證者保證通過驗證，但允許存在小概率例外；
零知識（Zero-Knowledge）：如果得到證明，無法從證明過程中獲知除了所證明信息之外的任何信息。
9.2、量子密碼學
量子密碼學（quantum cryptography）隨着量子計算和量子通信的研究而受到越來越多的關注，將會對已有的密碼學安全機制產生較大的影響。
量子計算的概念最早是物理學家費曼於1981年提出，基本原理是利用量子比特可以同時處於多個相干疊加態，理論上可以同時用少量量子比特來表達大量的信息，並同時進行處理，大大提高計算速度。如1994年提出的基於量子計算的Shor算法，理論上可以實現遠超經典計算速度的大數因子分解。這意味着大量加密算法包括RSA、DES、橢圓曲線算法等都將很容易被破解。但量子計算目前離實際可用的通用計算機還有一定距離。
量子通信則提供對密鑰進行安全分發的機制，有望實現無條件安全的“一次性密碼”。量子通信基於量子糾纏效應，兩個發生糾纏的量子可以進行遠距離的實時狀態同步。一旦信道被竊聽，則通信雙方會獲知該情況，丟棄此次傳輸的泄露信息。該性質十分適合進行大量的密鑰分發，如1984年提出的BB84協議，結合量子通道和公開信道，可以實現安全的密鑰分發。
提示：一次性密碼：最早由香農提出，實現理論上絕對安全的對稱加密。其特點爲密鑰真隨機且只使用一次；密鑰長度跟明文一致，加密過程爲兩者進行二進制異或操作。
9.3、社交工程學
密碼學與安全問題，一直是學術界和工業界都十分關心的重要話題，相關的技術也一直在不斷髮展和完善。然而，即便存在理論上完美的技術，也不存在完美的系統。無數例子證實，看起來設計十分完善的系統最後被攻破，並非是因爲設計上出現了深層次的漏洞，而問題往往出在事後看來十分淺顯的某些方面。
例如，系統管理員將登錄密碼貼到電腦前；財務人員在電話裏泄露用戶的個人敏感信息；公司職員隨意運行來自不明郵件的附件；不明人員借推銷或調查問卷的名義進入辦公場所竊取信息……
著名計算機黑客和安全顧問Kevin David Mitnick曾在15歲時成功入侵北美空中防務指揮系統，其著作《The Art of Deception》大量揭示瞭如何通過社交工程學的手段輕易獲取各種安全信息的案例。
十、小結
本章主要總結了密碼學與安全領域中的一些核心問題和經典算法。
通過閱讀本章內容，相信讀者已經對現代密碼學的發展狀況和關鍵技術有了初步瞭解。掌握這些知識，對於幫助理解區塊鏈系統如何實現隱私保護和安全防護都很有好處。
現代密碼學安全技術在設計上大量應用了十分專業的現代數學知識，如果讀者希望成爲這方面的專家，則需要進一步學習並深入掌握近現代的數學科學，特別是數論、抽象代數等相關內容。可以說，密碼學安全學科是沒有捷徑可走的。
另外，從應用的角度來看，一套完整的安全系統除了核心算法外，還包括協議、機制、系統、人員等多個方面。任何一個環節出現漏洞都將帶來巨大的安全風險。因此，要實現高安全可靠的系統是十分困難的。
區塊鏈技術中大量利用了現代密碼學的已有成果，包括哈希、加解密、簽名、Merkle樹數據結構等。另一方面，區塊鏈系統和諸多新的場景也對密碼學和安全技術提出了很多新的需求，反過來也將促進相關學科的進一步發展。
摘自：區塊鏈原理、設計與應用
