漫谈TLS nonce
密码学的基本原则之一是你不能把多条消息用同一种编码方式进行加密。那样的话，两条相同的明文会有相同的密文，这是个危险的漏洞。（这和你不能用ECB来加密块的道理类似。）
仔细考虑一下就会发现，一个纯粹的加密函数正像任何一个其他函数一样：具有确定的结果。在输入（编码方式和消息）相同的情况下，它总会返回相同的输出（加密后的消息）。而我们不想让攻击者知道这两条加密后的消息是由同一条明文编码来的。
解决办法是使用IV（初始向量）或nonce（只使用一次的数值）。因为对于每条加密消息，我们都可以使用不同的byte字符串。它们是非确定理论的起源，而这种理论要求制造出令人难以分辨的副本。这些消息通常不是什么秘密，但为了解密需要，我们会在分发时对它们进行加密。
IV与nonce之间的区别是有争议的，但也不是没有关联的。不同的加密方案所保护的侧重点也不同：有些方案需要的只是密文不重复，这种情况我们通常叫作nonce；还有一些方案需要密文是随机的，甚至完全不可预测的，这种情况我们通常叫作IV。
TLS中的nonce
TLS的核心是加密一个数据包的流，也称“记录”。首次握手关注的是对连接进行认证并生成密钥，然后由记录层以相同密钥对各种记录进行加密。
对Nonce的管理可能是个很有难度的问题，但TLS接近最完善的方案：在连接过程中，密钥永远不被重复使用，所有记录都有一个为通信双方所知晓的序列号。但需要对TLS协议做一些修改才能充分利用这一好处。
由此产生的景象有些复杂：
RC4算法和流密码
RC4是一个流密码，所以它不需要单独处理每一条记录。该密码生成一个连续的密钥流，它由明文经过异或运算产生，看起来就像是一条很长的消息的一部分。因此这里没有nonce。
RC4已经被攻破，TLS1.3版本已将其删除。
TLS1.0中的CBC
TLS1.0中的CBC的工作原理与RC4类似：密码只被实例化一次，然后记录就会被作为一个连续消息的一部分进行加密。
不幸的是，这意味着下一条记录的IV就是上一条记录的密文的最后一个块，攻击者也能观察到这一点。由于能够预见到IV会打破CBC的保护，这就导致了BEAST攻击。 将记录一分为二可以有效加强IV的随机性，从而减轻BEAST攻击的威胁，但这是一个客户端修补，不受服务器端的控制。
TLS 1.1以上版本中的CBC
TLS 1.1版本通过为每一条记录发送一个显式IV，修复了BEAST漏洞（随之而来的是网络的额外负担）。
AES-CBC的IV是16字节的（128位），所以使用随机字节足以防止冲突。
CBC还有另一个糟糕的设计问题，已被TLS1.3版本删除了。
TLS 1.2 中的GCM
TLS1.2继承了1.1版本中显式IV的做法。还像AES-GCM一样引入了AEAD。1.2版本的AES-GCM中的记录nonce由一个对应每个连接的固定IV（4个字节，与密钥同时产生）和一个对应每条记录的显式nonce（8个字节，在线路上发送）串接组成。
由于8个随机字节对于确保唯一性来说太短了，所以在1.2版本的GCM的实际应用中使用了序列号或计数器。如果你认为，“使用一个在线路上发送的仅作为通信双方都了解的序列号的显式IV有什么意义呢？”，这的确是有意义的。
一篇名为“不尊重nonce的对手”的论文发现，在实际应用中，不以计数器或序列为基础的AES-GCM的nonce的确易受攻击。
TLS1.3
TLS1.3最终利用了TLS记录的连续性，移除了自由形态的显式IV。它转而使用一个对应每个连接的固定IV（与密钥同时产生）和序列号的组合，该组合是经过异或运算而不是直接连接起来的。
这样整个nonce的长度看起来像是随机的，当序列号单调增加时，nonce永远不能重复使用，而且网络也没有额外负担。
ChaCha20-Poly1305算法
ChaCha20-Poly1305密码组使用TLS1.3中“固定IV与序列号进行异或运算”方案，该方案甚至已在TLS1.2中被使用。
虽然1.3版本的AEAD和1.2版本的ChaCha20使用相同的nonce方案，但1.2版本的ChaCha20仍将序列号、类型、版本和长度放在额外的认证数据中。而1.3版本将所有隐式的或加密的部分作为网络的有效载荷数据。
概述
- RC4是一个流密码，所以它没有对应每条记录的nonce。
- TLS 1.0中的CBC通常与RC4工作方式相似。不幸的是，这对于BEAST攻击来说很脆弱。
- TLS 1.1通过简单地将IV变为显式和随机而修复了BEAST漏洞。
- TLS 1.2中的AES-GCM使用一个固定IV和一个显式的连续nonce的串接。
- TLS 1.3最终选用了简单的固定IV和序列号进行异或运算。
- ChaCha20-Poly1305使用的3中的方案，在TLS1.2中就已使用。
对Nonce误用的抵抗
在简介中我们用一对同样的消息和密钥的例子来说明丢失和重复使用nonce的最直观的问题。但是，当相同的nonce被重复使用或可预测时，其他事情可能会出问题，而这取决于密码。
一个重复的nonce常常会毁掉整个连接的安全性。例如，AES-GCM的认证密钥被完全泄漏，这使得攻击者可以伪造数据包并注入数据。
作为密码学原始概念在实际应用中向更加安全地发展的趋势的一部分，这次研究关注的是减轻nonce重复使用的不良后果。这些新方案所具有的特性叫做nonce重用抵抗，但它们仍需要更更广泛的应用和标准化。这也是为什么一个像TLS1.3那样可靠的协议设计对于避免这类攻击是至关重要的原因所在。
本文由Filippo Valsorda于2016年10月12日发表在Cloudflare Blog。