TLS協議分析 (九) 現代加密通訊協議設計
轉自：http://chuansong.me/n/1286704052752
六. TLS協議給我們的啟發 — 現代加密通訊協議設計
在看了這麼多的分析和案例之後，我們已經可以歸納出加密通訊協議設計的普遍問題，和常見設計決策，
設計決策點：
-
四類基礎演算法 加密/MAC/簽名/金鑰交換 如何選擇？
對稱加密目前毫無疑問應該直接用aead，最佳選擇就是 aes-128-gcm/aes-256-gcm/chacha20-poly1305了
數字簽名/驗證方案，如果是移動網際網路，應該考慮直接放棄 RSA，考慮 P-256 的 ECDSA 公鑰證書，或者更進一步的 ed25519 公鑰證書。
金鑰交換演算法，目前最佳選擇就是 curve25519，或者 P-256。 -
對稱加密演算法+認證演算法，如何選擇？或者直接用aead？
-
簽名演算法如何選擇？RSA or ECDSA or Ed25519？
-
考慮將來的演算法調整，要加版本號機制嗎？
建議是加上，起碼在金鑰協商的步驟，要加上版本號。便於將來更新演算法。 -
RSA用作金鑰交換是一個好的選擇嗎？考慮PFS
建議直接放棄RSA，RSA伺服器端效能比ECDSA更差，簽名更大費流量，而且沒有前向安全性，給私鑰保管帶來更大風險。 -
自建PKI，是個好的選擇嗎？crl如何解決？
自建PKI可以做到更安全，比如簡單的客戶端內建數字簽名公鑰。可是當需要緊急吊銷一個證書的時候，只能通過緊急釋出新版客戶端來解決。 -
必須用糟糕的openssl嗎？or something better？crypto++,botan, nacl/libsodium, polarssl？libsodium: ed25519+curve2519+chacha20+poly1305
-
重放攻擊如何解決？某種seq？或者nonce如何生成？
-
握手過程被中間人篡改的問題怎麼解決？
-
效能：私鑰運算的cpu消耗可以承受嗎？加上某種cache？
要解決私鑰運算的高cpu消耗，必然就需要 session ticket/session id 這種cache機制。顯然session ticket 更好 -
延遲：金鑰協商需要幾個rtt？最少多少？加上cache後？和tcp對比如何
-
TLS的效能(主要指伺服器cpu消耗)還有空間可以壓榨嗎？我能設計一個性能更牛逼的嗎？
七. 附錄：密碼學基礎概念
本文已經很長了，基礎概念的內容更多，再展開介紹就太長了，下面就列一下點，貼一下參考資料，就先這樣,以後再說吧。
當然，最好的資料是下面列的書。
1. 塊加密演算法 block cipher
AES 等
2. 流加密演算法 stream cipher
RC4，ChaCha20 等
3. Hash函式 hash funtion
MD5，sha1，sha256，sha512 , ripemd 160，poly1305 等
4. 訊息驗證碼函式 message authentication code
HMAC-sha256，AEAD 等
5. 金鑰交換 key exchange
DH，ECDH，RSA，PFS方式的（DHE，ECDHE）等
6. 公鑰加密 public-key encryption
RSA，rabin-williams 等
使用什麼padding？ OAEP，為什麼不要用PKCS V1.5
7. 數字簽名演算法 signature algorithm
RSA，DSA，ECDSA (secp256r1 , ed25519) 等
8. 密碼衍生函式 key derivation function
TLS-12-PRF(SHA-256) , bcrypto，scrypto，pbkdf2 等
9. 隨機數生成器 random number generators
/dev/urandom 等