時刻關注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

獲取更多資訊請關注公眾號