時刻關注JDK進程或Oracle的童鞋都知道,JDK 11 已於6月底進入 Rampdown Phase One 階段，當時 JDK 11 的所有新特性就已被凍結，不再加入新的 JEP 。因爲近期寫了一些關於DES,3DES和AES算法的一些博文,所以對於JDK11裏所包含的17個新的JEP之一---ChaCha20 和 Poly1305 加密算法----就格外留意.
Chacha20-Poly1305 是由 Google 專門針對移動端 CPU 優化而採用的一種新式流式加密算法，它的性能相比普通算法要提高 3 倍，在 CPU 爲精簡指令集的 ARM 平臺上尤爲顯著（ARM v8前效果較明顯）。其中 Chacha20 是指對稱加密算法，Poly1305 是指身份認證算法。使用該算法，可減少加密解密所產生的數據量進而可以改善用戶體驗，減少等待時間，節省電池壽命等。由於其算法精簡、安全性強、兼容性強等特點，目前 Google致力於全面將其在移動端推廣。
從 Google 公司公佈的數據來看，Chacha20-Poly1305 能夠提升 30% 以上的加解密性能，可有效節省移動端耗電量。對比當前流行的加密套件 AES-GCM，在不支持 AES NI 指令的硬件設備上，該算法會引起性能問題，如大部分的智能手機、平板電腦以及可穿戴設備。總的來說，在部分移動設備上，ChaCha20-Poly1305 加密的速度是 AES 的 3 倍還多。也即在使用 ChaCha20-Poly1305 時，較舊的計算機或者移動端設備在加解密方面會花費更少的計算時間，減少加解密時間意味着更快的頁面加載速度以及更少的設備電池消耗。
針對移動端設備，我們很容易得出這樣的結論和解決方案：在具有硬件 AES 支持的 PC 電腦上，使用 AES-GCM 算法無疑是不錯的選擇；又拍雲 CDN 平臺會根據客戶端支持的加密套件情況來智能選擇是否提供 AES-GCM 還是 ChaCha20-Poly1305。對於最新的英特爾處理器，我們會使用標準的 AES-GCM 算法；對於沒有硬件 AES 支持的設備來說，我們會優先選擇 ChaCha20-Poly1305。
就安全性而言，ChaCha20-Poly1305 加密套件使用了兩種算法，其中 Chacha20 是指對稱加密算法，Poly1305 是指身份認證算法。從 RFC 文檔裏面可以得知，ChaCha20 提供了 256 位的加密強度，這對於 AES-GCM 算法的 128 位的加密強度來說，已經綽綽有餘。也就是說，使用 ChaCha20 作爲對稱加密算法來保障 HTTPS 安全性已經足夠了。
Poly1305 作爲身份認證算法提供身份驗證，可以防止攻擊者在 TLS 握手過程中，將虛假信息插入到安全的數據流中，Poly1305 提供了大約 100 位的安全性，足以阻止這類攻擊。在 TLS 握手過程中，身份驗證相比加密並沒有那麼重要，因爲即使攻擊者可以向數據流中添加虛假消息，在密鑰信息沒有被破解的情況下，也不會讀取到內部的數據信息。
總之，ChaCha20-Poly1305 作爲一個加密組合，可同時對數據提供機密性，完整性和真實性保證，避開了現有發現的所有安全漏洞和攻擊，是一組極佳的加密套件組合。
期待JDK11的正式公佈,到時候再給大家更新一波Java實現。
未經允許,謝絕轉載.如果大家有什麼建議或問題,歡迎大家進羣討論,另羣裏有學習資料奉送哦羣號爲: 661594029
獲取更多資訊請關注公衆號
