不久前，我们为所有客户推出了基于ChaCha20-poly1305aead的TLS密码套件支持。那时，这些密码套件只被Chrome浏览器和Google的网站支持，但正在标准化的过程中。我们引入这些密码套件是为了给移动设备上的终端用户提供尽可能最好的性能和安全性。CC BY-ND 2.0图像，作者：Edwin Lee今天，标准化过程几乎已经完成，密码套件最新规范的实现已经开始浮出水面。Firefox和OpenSSL都为即将到来的版本实现了新的密码套件，Chrome也更新了它的实现。作为ChaCha20-Poly1305在网络上的应用的先驱者，我们也更新了OpenSSL的开源补丁。它既实现了旧的"草稿"版本，以继续支持现有Chrome版本的数百万用户，也实现了新的"RFC"版本，从第一天起支持即将到来的浏览器。在这篇博客文章中，我回顾了ChaCha20-Poly1305的历史，它的标准化过程，以及它对web未来的重要性。我还将看看它的性能，与其他标准的AEAD相比。什么是AEAD？ChaCha20-Poly1305是一个AEAD，通过附加数据密码进行认证加密。AEADs支持两种操作："密封"和"打开"。用于TLS连接的另一个常见AEAD是AES-GCM。2.0图片由杰里米·基思提供"密封"操作接收以下输入：要加密的消息-这是明文。一把密匙。一个唯一的初始化值-也称为IV。它必须在使用相同密钥的"seal"操作调用之间是唯一的，否则密码的保密性将完全受损。可选的一些其他非机密的附加数据。此数据不会被加密，但将被验证-这是AEAD中的广告。"seal"操作使用密钥和IV，使用底层密码将明文加密为长度相等的密文。对于ChaCha20-Poly1305，密码为ChaCha20，对于AES-GCM（另一种常用AEAD），密码为AES计数器模式（AES-CTR）。在数据被加密后，"seal"使用密钥（以及可选的IV）来生成一个辅助密钥。第二个密钥用于生成广告、密文和每个密文长度的键控哈希。ChaCha20-Poly1305中使用的散列是Poly1305，而在AES-GCM中，hash是GHASH。最后一步是获取哈希值并对其进行加密，生成最终的MAC（消息认证码）并将其附加到密文中。CC BY-SA 2.0图片作者：Kai Schreiber"打开"操作与"密封"相反。它使用相同的密钥和IV，生成密文和广告的MAC，类似于"seal"的方式。然后读取附加在密文后面的MAC，并将两者进行比较。MAC值的任何差异都意味着密文或广告被篡改了，它们应该被视为不安全而丢弃。但是，如果两者匹配，则操作将解密密文，返回原始明文。AEADs的特殊之处是什么？AEAD的特殊之处在于，它们将密码和MAC两种算法组合成一个单一的原语，具有可证明的安全保证。在AEADs之前，可以接受一些被认为是独立安全的密码和MAC，并将它们组合成不安全的组合。例如，一些组合通过重复使用相同的密钥进行加密和MAC（AES-CBC和CBC-MAC）而被破坏，而另一些组合则是通过明文执行MAC，而不是在TLS中使用HMAC的密文AES-CBC。新来的孩子直到最近，AEAD使用的唯一标准是AES-GCM。问题是，如果有人打破了GCM模式，我们就别无选择——你不会想在没有备用降落伞的情况下跳出飞机吧？ChaCha20-Poly1305是备用的。lina smith的CC BY 2.0图像我们不能称ChaCha20或Poly1305真的是新的。两人都是丹尼尔伯恩斯坦（danielj.Bernstein，DJB）的大脑孩子。ChaCha20是基于DJB开发的一种早期密码Salsa，可以追溯到2005年，并提交给了eSTREAM竞赛。ChaCha20本身于2008年出版。它对萨尔萨回合稍作修改，数字20表示它总共重复20回合。与AES-CTR类似，ChaCha20是一种流密码。它从递增计数器生成一个伪随机比特流，然后用明文对该流进行"XORed"加密（或用密文"XORed"解密）。因为您不需要预先知道明文来生成流，所以这种方法既可以非常高效又可以并行化。ChaCha20是一个256位的密码。Poly1305于2004年出版。Poly1305是一种MAC，可以与任何加密或未加密的消息一起使用，以生成密钥认证令牌。这种令牌的目的是保证给定消息的完整性。最初Poly1305使用AES作为底层密码（poly1305aes）；现在它使用ChaCha20。同样，与GHASH类似，它是一个多项式求值散列。与GHASH不同的是，每一条新消息的关键都会改变，因为它依赖于IV。当DJB开发这种MAC时，他特别适合在cpu上的浮点硬件上高效执行。今天，使用64位整数指令执行更为高效，而且设计可能略有不同。自那以后的几年里，这两种技术都受到了加密界的严格审查，如今被认为是完全安全的，尽管有人担心当一个人负责行业中如此多的标准时形成的单一文化（DJB也负责Curve25519密钥交换）。从零到英雄管理互联网标准的机构是IETF-互联网工程任务组。我们在互联网上使用的所有标准，包括TLS，都来自该组织。所有与加密相关的标准都来自IETF的TLS和CFRG工作组。标准化进程对所有人开放，与之相关的信件在专门的档案馆中公开。我在档案中发现的关于ChaCha20-Poly1305的第一次提及可以追溯到2013年7月30日。那时候还是叫萨尔萨。经过一段时间的讨论，谷歌的亚当·兰利于2013年9月发布了一份初稿。关于TLS的ChaCha20-Poly1305的最新草案，包括所有以前的修订版都可以在这里找到。有趣的是，我们可以看到渐进式的过程和逐渐的改进。例如，最初ChaCha20也应该与HMAC-SHA1一起工作。另一个定义ChaCha20-Poly1305的一般用法的标准是RFC7539。2014年1月首次发布，2015年5月标准化。差异我们最初实现的草案版本和当前版本的密码套件之间有两个关键的区别，这两个版本是不兼容的。第一个区别是如何在TLS中使用密码套件。当前版本将TLS记录序列号合并到IV生成中，使其更能抵抗危险的IV重用。第二个区别与Poly1305如何应用于TLS记录有关。记录相当于TLS的TCP数据包。当数据通过TLS传输时，它被分成许多更小的记录。每个记录保存部分数据（加密），并计算该记录的MAC。它还保存其他信息，如协议版本、记录类型和长度。单个记录可以保存的最大数据量为16KB。Poly1305草案计算了附加数据的哈希值，然后将附加数据的长度计算为8字节字符串，接着是密文，然后是8字节字符串的密文长度。在当前迭代中，哈希是在附加数据上生成的，用0填充到16字节的边界，然后是密文，类似地用零填充，然后是附加数据的长度作为8字节字符串，接着是密文的长度作为8字节字符串。旧的密码套件可以通过id{cc}{13}、{cc}{14}和{cc}{15}来识别，而较新的密码套件具有id{cc}{a8}到{cc}{ae}。未来的Polycha1305-1305今天，我们已经看到，使用CloudFlare的站点的所有请求中，有近20%使用ChaCha20-Poly1305。只有一个浏览器支持它。在接下来的几个月里，Firefox将加入该党，可能会增加这个数字。更重要的是，IETF目前正在完成另一个非常重要的标准tls1.3。现在看来TLS1.3只允许AEADs，剩下AES-GCM和ChaCha20-Poly1305是唯一的两个选项（目前）。这肯定会大大提高ChaCha20-Poly1305的使用率。你能搞定吗？考虑到ChaCha20-Poly1305套件和TLS的日益流行，有一个高效的实现是很重要的，它不会占用服务器太多的CPU时间。ChaCha20-Poly1305允许使用SIMD指令高效地实现。我们的大多数服务器都是基于Intel CPU的256位SIMD扩展名AVX2。我们利用这些来获得最大的性能。ChaCha20-Poly1305的主要竞争对手是基于AES-GCM的密码套件。最广泛使用的AES-GCM使用128位密钥的AES，但是在安全性方面，AES-256与ChaCha20相比更具可比性。通常情况下，大消息的密码性能数字会被报告，以显示渐近性能，但在我们的网络中，我们开始使用动态记录大小调整。实际上，这意味着许多连接永远不会达到TLS记录的最大大小（16KB），而是使用更小的记录（低于1400字节）。记录会随着连接的进行而动态增长，扩展到大约4KB，最终扩展到16KB。大多数消息也不能精确地放入一个记录中，所有大小都是可能的。下面是两张图，比较了我们的ChaCha20-Poly1305与openssl1.1.0pre中的实现和AES-GCM的性能。性能以每字节的CPU周期为单位报告，fo