標籤:學習 流式 公眾號 平板電腦 防止 ado 公眾 對稱式加密 aes
時刻關注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擷取更多資訊請關注公眾號
淺談JAVA11中新增的密碼編譯演算法