libsodium AEAD 实施背后的决定答案

【问题标题】：Decision behind libsodium AEAD implementationlibsodium AEAD 实施背后的决定
【发布时间】：2018-07-07 13:04:24
【问题描述】：

RFC 7539 定义其 AEAD 结构如下：

chacha20_aead_encrypt(aad, key, iv, constant, plaintext):
   nonce = constant | iv
   otk = poly1305_key_gen(key, nonce)
   ciphertext = chacha20_encrypt(key, 1, nonce, plaintext)
   mac_data = aad | pad16(aad)
   mac_data |= ciphertext | pad16(ciphertext)
   mac_data |= num_to_4_le_bytes(aad.length)
   mac_data |= num_to_4_le_bytes(ciphertext.length)
   tag = poly1305_mac(mac_data, otk)
   return (ciphertext, tag)

另一方面，libsodium 实现如下：

chacha20_aead_encrypt(aad, key, iv, constant, plaintext):
   nonce = constant | iv
   otk = poly1305_key_gen(key, nonce)
   ciphertext = chacha20_encrypt(key, 1, nonce, plaintext)
   mac_data = aad
   mac_data |= num_to_8_le_bytes(aad.length)
   mac_data |= ciphertext
   mac_data |= num_to_8_le_bytes(ciphertext.length)
   tag = poly1305_mac(mac_data, otk)
   return (ciphertext, tag)

基本上，libsodium 在其 Poly1305 通道上不使用填充和交错数据和元数据（其长度）。由于块对齐问题，这对优化非常不友好：计算附加数据的 MAC 后，下一个数据不需要块对齐，因此不能使用高度优化和交错的 Chacha20-Poly1305 构造。

这个决定背后的原因是什么？

【问题讨论】：

为什么不问问作者呢？一个措辞良好的问题通常会得到回答。加密的好处是我们拥有大多数密码学家还活着的奢侈:)

标签： cryptography libsodium

【解决方案1】：

引用https://download.libsodium.org/doc/secret-key_cryptography/aead/chacha20-poly1305“libsodium 实现了三个版本的 ChaCha20-Poly1305 构造”。前两个如下：

原结构可以安全加密多达 2^64 条相同的消息密钥（对于大多数协议甚至更多），对大小没有任何实际限制消息的长度（对于 128 位标签，最多 2^64 个字节）。
IETF 变体。它可以安全地加密几乎无限数量的消息，但单个消息不能超过 64*(2^32)-64 字节（大约 256 GB）。

你描述的是“原始结构”。正如您所观察到的，原始构造支持的随机数小于 IETF 版本（64 位与 96 位），AEAD 构造也不同。

我的猜测：“原始构造”是在编写 IETF RFC 之前开发的。 libsodium 基于https://en.wikipedia.org/wiki/NaCl_(software)，最初于 2008 年发布。IETF RFC 编写于 2015 年。

【讨论】：