一、對稱密碼
1、機密性（看不到明文）
2、算法：
DES(Data Encryption Standard)：已被暴力破解
三重DES(3DES、EDEA）：過程 加密（秘鑰1）-解密（秘鑰2）-加密（秘鑰3）
（1）DES-EDE2：秘鑰1和秘鑰3相同 和
（2）DES-EDE3：秘鑰均不同
特點：安全性可以，但處理速度不高。
AES(Advanced Encryption Standard 美國通過組織AES公開競選算法,免費供全世界使用)：取代DES和三重DES的標准算法。
特點：安全、快速
選定的算法為Rijndael算法。
3.DES與AES屬於分組密碼，只能加密固定長度的明文。更多密文時需要分組、迭代加密。
如AES分組長度為128比特、可以一次性加密128比特的明文，並生成128比特的密文
4.分組密碼模式
ECB模式：每個組直接用相同秘鑰直接加密。絕對不可用
CBC模式：推薦
CTR模式：推薦
CFB模式：推薦
OFB模式：推薦
ps：SSL/TLS協議使用了CBC模式，用了三重DES的3DES_EDE_CBC以及AES_256_CBC
缺點：秘鑰配送的問題。-->可以用公鑰密碼（非對稱加密）解決。
嘗試解決配送問題：
（1）事先共享秘鑰
當然能見面、打電話確認或者郵件確認的方式實現共享秘鑰自然可以，這類場景不會存在配送的問題。
能事先共享秘鑰時也有問題：人與人之間都需要不同的秘鑰。數量太多。如果有N個人，那么就需要N*(N-1)/2個秘鑰
但其他場景，比如瀏覽器與服務器，怎樣建立起信任？剛認識的朋友之間的消息，如何信任呢？
（2）秘鑰分配中心：每個人都通過中心分配。
缺點：數據庫保存太多的秘鑰、同時秘鑰分配中心責任重大
（3）Diffie-Hellman秘鑰交換方式
（4）公鑰密碼（非對稱加密）
二、非對稱密碼（公鑰密碼）
1、機密性（看不到明文）
2、原理：消息接收者A生成秘鑰對，包含公鑰和私鑰。公鑰發送給消息發送者B。消息發送者B用A的公鑰對消息進行加密，這樣A可以用私鑰界面。
（竊聽者能看到公鑰，也能看到界面的密文，但是由於沒有私鑰，所以無法解密出消息）
3.算法：
（1）RSA:使用最廣泛
特點：明文、秘鑰和密文都是數字。
（2）其他算法ElGamal方式、Rabin方式、橢圓曲線密碼方式。
橢圓曲線密碼方式秘鑰短但是強度高，也被廣泛使用。
SSL/TLS用了橢圓曲線Diffie-Hellman秘鑰交換（ECDH、ECDHE）和橢圓曲線DSA(ECDSA);
比特幣使用了橢圓曲線DSA用於數字簽名。
（3）Diffie-Hellman秘鑰交換：從公開數字無法推斷出秘鑰。 SSL/TLS中有使用到。
1.通訊方A生成隨機數a、通訊方B生成隨機數b。
A發送Diffie-Hellman公開值：A的計算值（G^a / P） 、G、P
B發送Diffie-Hellman公開值：B的計算值 (G^b / P)
2. A和B計算出的秘鑰是相等的,都是G^(a * b) / p
A的計算秘鑰：（B的計算值）^a / P
B的計算秘鑰：（A的計算值）^b / P
說明：從公開的數字，是無法計算出秘鑰的（數學上可以論證）。
Diffie-Hellman秘鑰交換計算出的密碼是共享密碼，無法避免中間人攻擊。
4.缺點：
（1）加密大量文件時，速度慢（速度遠遠低於對稱密碼）
解決：通過混合密碼系統解決。
（2）中間人攻擊
A向B索取公鑰時，B發送公鑰給A時，被中間人C竊聽、劫持並保存了B的公鑰，C把自己的公鑰給A，這樣A通過C的公鑰加密的信息C能讀到。
C也能給B發送消息。
解決：需要公鑰認證。
三、混合密碼系統：對稱密碼 + 公鑰密碼（非對稱密碼）
1.特點：會話秘鑰作為對稱密碼的秘鑰，同時也是公鑰密碼的明文。
（1）會話秘鑰（偽隨機生成器生成）
（2）對稱密碼方式（消息，會話秘鑰）
（3）公鑰密碼方式（會話秘鑰，接受者公鑰） - 會話秘鑰不會太長
長期考慮：公鑰密碼強度要高於對稱密碼。
2、應用：著名密碼軟件PGP 和 SSL/TLS都有運用。
四、單向散列函數（消息摘要、哈希函數）：不可逆，不能反推出明文
1、完整性（檢測篡改）
2.特點：
（1）計算速度快、
（2）消息再長計算出的散列值也是固定的長度，如SHA-256長度永遠是236比特（32字節）
（3）消息不同，那么計算出的散列值也不同
3.應用：基於口令的加密（PBE）、消息認證碼、數字簽名、偽隨機生成器
4.算法：
MD5：已被攻破，不安全
RIPEMD-160：已被攻破，不安全
SHA-1：已被攻破，不安全
SHA-2包括SHA-224、SHA-256、SHA-384、SHA-512 推薦
SHA-3：單向散列函數新標准。Keccak被選定為SHA-3算法。 推薦
SHA3-224、SHA3-256、SHA3-384、SHA3-512
缺點：能識別篡改，但是不能識別偽裝。
五、消息認證碼（Message Authentication Code）簡稱MAC：單向散列函數 + 共享秘鑰
1.完整性（檢測篡改）、認證對方身份（檢測偽裝）
2.實現方式：
（1）單向散列函數（消息 + 共享秘鑰） 和 消息一起傳送
變形： 單向散列函數（對稱加密（消息，共享秘鑰） + 共享秘鑰） 和 對稱加密（消息，共享秘鑰）一起傳送
（2）也可以使用AES之類的分組密碼實現：分組秘鑰作為消息的共享秘鑰並用CBC模式將消息加密。如AES-CMAC是一種消息認證碼
（3）也可以使用流密碼和公鑰密碼方式。
GCM是一種認證加密的方式，采用AES_128_CTR模式。 專門用於消息認證碼的GCM稱為GMAC。
GCM和CCM(CBC count Mode)都被列為推薦的認證加密方式。
3.算法：
HMAC:用單向散列函數來構建的消息認證碼。比如HMAC-SHA-224、HMAC-SHA-256、HMAC-SHA-384、HMAC-SHA-512
4.應用：
（1）銀行與銀行之間的傳遞消息通過SWIFT(環球銀行金融電信協會)完成，SWIFT使用了消息認證碼。
（2）IPsec對IP協議的增強，使用了消息認證碼。
（3）SSL/TLS也使用了消息認證碼
（4）公司系統調用接口：
案例a.訪問外部系統頁面：A=xxx&B=xxx&time=xxx&sign=HMAC-SHA1(A=xxx&B=xxx&time=xxx , key秘鑰)
模式：單向散列函數（消息 + 共享秘鑰） + 消息
案例b.支付URL：A=xxx&B=xxx&Sign=MD5(A=xxx&B=xxx&Key=xxx)
模式：單向散列函數（消息 + 共享秘鑰） + 消息
案例c.接口調用： MD5( URLEncoder.encode(content,'UTF-8') + 簽名Key) + URLEncoder.encode(content,'UTF-8')
模式：單向散列函數（消息 + 共享秘鑰） + 消息
javascript中一般采用encodeURIComponent函數對特殊字符進行編碼。
Java中可以使用函數URLEncoder.encode對特殊字符進行編碼。
百度地圖開放平台中用的也是這種，只是用的加密方式為公鑰密碼，簽名Key為公鑰。
案例d.接口調用：
http時： MD5（AES（content，SECRET_KEY）+ SECRET_KEY） 和 AES（content，SECRET_KEY）
參數： accessKey=ACCESS_KEY&signature=MD5（AES（content，SECRET_KEY）+SECRET_KEY）
內容： AES（content，SECRET_KEY）
https時： MD5（content+ SECRET_KEY） 和 content
參數： accessKey=ACCESS_KEY&signature=MD5（content+SECRET_KEY）
內容： content
5.缺點：
（1）需要實現共享秘鑰，所以同樣存在秘鑰配送問題。
解決：參見對稱加密的幾種方式。
（2）無法防止否認。
比如：A發消息給B，B知道A發了消息，但是A可以抵賴，這時無法像第三方證明是A發送的(）。
因為A和B都知道密碼，有可能是B污蔑A,第三方也無法判定誰是對的。
解決：數字簽名
（3）重放攻擊：竊聽者把A發送給B的消息，原樣發送一次。如果是一個匯款，那么等於發生了多次匯款。
解決：
a.序號方式：每次通訊都對消息加一個序號，計算MAC時把需要加入。下一次通訊對序號加1。
難度：序號需要通訊方維護和管理。
b.時間戳 - 存在時間同步問題。如果考慮延遲，那么又會給重放攻擊機會。
c.隨機數 ：客戶端保證每次請求的隨機數不同 - 時間戳相關的生成，服務器存儲已經使用的隨機數。
問題：服務器存儲的隨機數無限大。
解決方式： 時間戳 和 隨機數一起使用。 比如服務器設置時間戳的誤差為2分鍾，那么隨機數的存儲也只需要存儲2分鍾。
六、數字簽名：單向散列函數 + 公鑰密碼
1.完整性（檢測篡改）、認證對方身份（檢測偽裝）、不可否認（對方不能否認）
2.原理：
（1）發送方A生成公鑰密碼對。
（2）A發送內容包括：A私鑰加密消息生成簽名（簽名中包含了A的公鑰--供對方或第三方認證機構驗證簽名） + 消息
（3）B用A的公鑰驗證A的簽名
3.優化：第二部有個問題：A私鑰直接加密消息是很慢的，所以可以用單向散列函數先處理，然后再用秘鑰加密。如下：
公鑰密碼（單向散列函數（消息），A私鑰） + 消息 （推薦）
4.說明
（1）簽名並不能保證機密性。如果需要消息的機密性，可以組合對稱加密的方式。參見后面。
（2）簽名不能保證消息不被修改，但是被修改后可以識別出來。
(3) 數字簽名的不可否認性：因為私鑰是發送者才有
（4）數字簽名代替紙質簽名：存在風險、需要未來完善
（5）軟件作者可以加上數字簽名，下載軟件者，只要驗證數字簽名就能識別是否被篡改。
（6）數字簽名只是能檢測是否被篡改，如果軟件作者有惡意行為，那沒辦法。
5.缺點：存在中間人攻擊，需要證明公鑰是否合法（公鑰是否屬於發送者）
解決：為了證明自己的公鑰合法，需要數字證書。
七、公鑰證書（證書）：個人信息（包含公鑰） + 數字簽名
1.流程：
（1）A向認證機構注冊自己的公鑰。 認證機構用自己的私鑰給A加數字簽名並生成證書。
（2）發送消息時不再直接發送自己的公鑰，而是發送包含公鑰的證書（包含認證機構對發送者公鑰的數字簽名 和 發送者的公鑰）。
（3）接受方可以用認證機構的公鑰驗證數字簽名，確認發送方公鑰的合法性
說明：接收者收到證書並驗證合法后，會把發送方的秘鑰存在電腦，下次通訊直接使用。
2.注冊公鑰時，認證機構需要確認注冊者的真實身份。可能的方式：電話、郵件、查詢第三方數據庫、當面認證和身份證明等，根據等級不同等級的認證。
3.證書標准：X.509規范
4.公鑰基礎設施（Public Key Infrastructure）PKI ：公鑰規范總稱。X.509也是PKI的一項標准。
（1）三要素：
用戶 ：生成密鑰對（也可以由認證機構生成）、申請證書、申請作廢證書
認證機構：用戶注冊時認證身份、頒發證書、作廢證書。
倉庫：存儲證書
（2）證書的層級由上級機構驗證下級機構的公鑰，迭代下去。直到根CA(Root CA)，根CA用自己的公鑰。
當然，這些過程都是電子郵件、瀏覽器等軟件完成的。
（3）認證機構只要對公鑰進行數字簽名就可以，任何人或者機構都能成為PKI。但如果不采用權威的PKI,通訊雙方可能不會信任。
如對於瀏覽器訪問https協議的網頁，服務器會把數字證書和網頁發送回客戶端
a.如果不在瀏覽器“受信任的根證書頒發機構”列表中，會彈出證書的認證機構是否可信任的提示。
此時用戶可以選擇不可信任，或者添加到“受信任的根證書頒發機構”列表。
b.如果數字證書信息不對或者證書失效等，瀏覽器會發出警告。
5.理解
（1）如果能取得可信的公鑰，那么不需要認證機構。
（2）當持有可信的認證機構公鑰切相信認證機構所進行的身份認證，可以信任該認證機構頒發的證書以及通訊方的公鑰
（3）通過自己的方法認證是不安全的- 依靠隱蔽保證安全是錯誤的
6.應用：
（1）正式使用的證書一般是收費的。賽門鐵克提供個人證書。
個人網站或開發者可以用騰訊雲的免費證書。
（2） USB KEY 方式（U盾）： 客戶端證書和秘鑰都放在USB中，不經過網絡傳輸。
（3） RSA公司制定的PKCS (Public-Key Cryptography Standards)規范也屬於PKI的一種，PKCS 目前共發布過 15 個標准。
PKCS#7：密碼消息語法標准。PKCS#7為使用密碼算法的數據規定了通用語法，比如數字簽名和數字信封。
PKCS#7提供了許多格式選項，包括未加密或簽名的格式化消息、已封裝（加密）消息、已簽名消息和既經過簽名又經過加密的消息。
說明：公司中保險電子保單中，要求使用PKCS#7標准簽名。
PKCS 目前共發布過 15 個標准：
（1）PKCS#1：RSA加密標准。PKCS#1定義了RSA公鑰函數的基本格式標准，特別是數字簽名。它定義了數字簽名如何計算，包括待簽名數據和簽名本身的格式；它也定義了PSA公/私鑰的語法。
（2）PKCS#2：涉及了RSA的消息摘要加密，這已被並入PKCS#1中。
（3）PKCS#3：Diffie-Hellman密鑰協議標准。PKCS#3描述了一種實現Diffie- Hellman密鑰協議的方法。
（4）PKCS#4：最初是規定RSA密鑰語法的，現已經被包含進PKCS#1中。
（5）PKCS#5：基於口令的加密標准。PKCS#5描述了使用由口令生成的密鑰來加密8位位組串並產生一個加密的8位位組串的方法。PKCS#5可以用於加密私鑰，以便於密鑰的安全傳輸（這在PKCS#8中描述）。
（6）PKCS#6：擴展證書語法標准。PKCS#6定義了提供附加實體信息的X.509證書屬性擴展的語法（當PKCS#6第一次發布時，X.509還不支持擴展。這些擴展因此被包括在X.509中）。
（7）PKCS#7：密碼消息語法標准。PKCS#7為使用密碼算法的數據規定了通用語法，比如數字簽名和數字信封。PKCS#7提供了許多格式選項，包括未加密或簽名的格式化消息、已封裝（加密）消息、已簽名消息和既經過簽名又經過加密的消息。
（8）PKCS#8：私鑰信息語法標准。PKCS#8定義了私鑰信息語法和加密私鑰語法，其中私鑰加密使用了PKCS#5標准。
（9）PKCS#9：可選屬性類型。PKCS#9定義了PKCS#6擴展證書、PKCS#7數字簽名消息、PKCS#8私鑰信息和PKCS#10證書簽名請求中要用到的可選屬性類型。已定義的證書屬性包括E-mail地址、無格式姓名、內容類型、消息摘要、簽名時間、簽名副本（counter signature）、質詢口令字和擴展證書屬性。
（10）PKCS#10：證書請求語法標准。PKCS#10定義了證書請求的語法。證書請求包含了一個唯一識別名、公鑰和可選的一組屬性，它們一起被請求證書的實體簽名（證書管理協議中的PKIX證書請求消息就是一個PKCS#10）。
（11）PKCS#11：密碼令牌接口標准。PKCS#11或“Cryptoki”為擁有密碼信息（如加密密鑰和證書）和執行密碼學函數的單用戶設備定義了一個應用程序接口（API）。智能卡就是實現Cryptoki的典型設備。注意：Cryptoki定義了密碼函數接口，但並未指明設備具體如何實現這些函數。而且Cryptoki只說明了密碼接口，並未定義對設備來說可能有用的其他接口，如訪問設備的文件系統接口。
（12）PKCS#12：個人信息交換語法標准。PKCS#12定義了個人身份信息（包括私鑰、證書、各種秘密和擴展字段）的格式。PKCS#12有助於傳輸證書及對應的私鑰，於是用戶可以在不同設備間移動他們的個人身份信息。
（13）PDCS#13：橢圓曲線密碼標准。PKCS#13標准當前正在完善之中。它包括橢圓曲線參數的生成和驗證、密鑰生成和驗證、數字簽名和公鑰加密，還有密鑰協定，以及參數、密鑰和方案標識的ASN.1語法。
（14）PKCS#14：偽隨機數產生標准。PKCS#14標准當前正在完善之中。為什么隨機數生成也需要建立自己的標准呢？PKI中用到的許多基本的密碼學函數，如密鑰生成和Diffie-Hellman共享密鑰協商，都需要使用隨機數。然而，如果“隨機數”不是隨機的，而是取自一個可預測的取值集合，那么密碼學函數就不再是絕對安全了，因為它的取值被限於一個縮小了的值域中。因此，安全偽隨機數的生成對於PKI的安全極為關鍵。
（15）PKCS#15：密碼令牌信息語法標准。PKCS#15通過定義令牌上存儲的密碼對象的通用格式來增進密碼令牌的互操作性。在實現PKCS#15的設備上存儲的數據對於使用該設備的所有應用程序來說都是一樣的，盡管實際上在內部實現時可能所用的格式不同。PKCS#15的實現扮演了翻譯家的角色，它在卡的內部格式與應用程序支持的數據格式間進行轉換。
八、秘鑰
1、會話秘鑰與主秘鑰 ：Https通訊時，會使用會話秘鑰（一次性秘鑰）
2、CEK（Content Encrypting Key 內容加密秘鑰） 和 KEK（Key Encrypting Key 秘鑰加密秘鑰)
3.秘鑰的生成：
（1）隨機數生成：用專門針對密碼學用途的偽隨機生成器
（2）基於口令的密碼： 單向散列函數（口令 + 鹽salt） 如PBE
4.配送秘鑰：見第一節
5.PBE（ Password Based Encryption 基於口令的加密）
偽隨機數生成器-->鹽salt
單向散列函數（口令 + 鹽salt）生成KEK(秘鑰加密秘鑰)
偽隨機數生成器-->會話秘鑰CEK（內容加密秘鑰）
對稱加密（消息，會話秘鑰CEK）
對稱加密（會話秘鑰CEK，KEK）
說明：
（1）鹽salt的作用：相當於增加密碼的復雜度
（2）鹽salt和會話秘鑰是隨機生成的，都是一次會話中使用，下次會話要生成新的。
注意：一次會話並不是一次通訊。
在會話期間，電腦需要存儲鹽和加密后的CEK。
（3）javax.crypto有實現。
九、偽隨機生成器：用於生成秘鑰。可以用對稱密碼、單向散列函數或者公鑰密碼構建。
1.方法：
單向散列函數法
密碼法
ANSI X9.17 :被用於了PGP中。
2.java.util.Random 不能用於安全相關用途。可以用java.security.SecureRandom替代
十、PGP密碼軟件-密碼技術的完美組合。（GnuPG也是一款類似的軟件）
1.功能：對稱密碼、公鑰密碼、數字簽名、單向散列函數、證書、壓縮、文本數據（二進制與文本數據的相互轉換）、鑰匙串管理、大文件拆分與拼合。
2.涉及公鑰合法性時，PGP沒有使用認證機構、而是采用了信任網的方式（PGP用戶相互信任對方）。
私鑰的保存：
（1）基於口令的密碼： 單向散列函數（口令 + 鹽salt） 生成私鑰的加密密鑰
（2）用PEB對私鑰進行加密。
使用時：用口令獲取PPE，然后對加密后的私鑰進行解密。
十一、SSL/TLS （Secure Socket Layer 安全套階層 Transport Layer Secure 傳輸層安全）
1.SSL/TLS之上承載的HTTP、SMTP、POP3。
TLS是在SSL3.0基礎上設計的協議，相當於SSL3.1。
2.先進行SSL/TLS層協議，然后在執行其上的協議。比如http三次握手
3.TLS生成主密碼方式：
（1）生成預備主密碼的兩種方式
先生成，然后用公鑰密碼方式傳輸。
Diffie-Hellman秘鑰交換直接生成。
（2）主密碼由預備主密碼 + 客戶端隨機數 + 服務器隨機數生成，用密碼套件中定義的單向散列函數（如SHA-256）計算生成。
十二、虛擬貨幣-比特幣
1.比特幣是一種基於P2P網絡（由所有比特幣用戶組成）的支付結算系統。
2.區塊鏈是保存比特幣交易的公共賬簿，記錄了迄今為止所有的交易。而且是透明的，任何人都可以驗證交易。
3.比特幣地址：交易是在比特幣地址直接完成的。多數情況下會為每一筆交易創建不同的地址。但是在比如捐贈等場景中，也會反復使用同一地址。
比特幣的地址是有公鑰的散列生成。
橢圓曲線DSA的公鑰輸入SHA-256和RIPEMD-160兩個單向散列函數計算散列值，附加一些信息后再用Base58Check進行編碼，轉換成字符串。
4.比特幣的客戶端：錢包。 用戶通過錢包生成秘鑰對，公鑰用於接收比特幣，私鑰用於支付比特幣。
5.區塊鏈維護：
（1）區塊中任意一比特被修改，那么必須重建區塊之后的所有區塊的數據。
（2）需要有人把新的區塊添加到區塊鏈中，稱為挖礦。成功添加新的區塊的礦工能獲取獎勵。
（3）同一時間點出現了多個符合要求的散列值，那么區塊鏈可能產生分支。
通常需要確認，通常選擇把計算量大的分支繼續工作，壓制區塊鏈繼續分支。
6.交易
使用了數字簽名技術。其中數字簽名的算法為橢圓曲線DSA
十三、常識
1.不要使用保密的密碼算法，公開的算法都是世界公認的，安全性更有保障。
2.任何密碼總有一天被破解