时刻关注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获取更多资讯请关注公众号
原文地址：http://blog.51cto.com/13884944/2153438