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构造。
此决定背后的原因是什么?
答案 0 :(得分:1)
引用https://download.libsodium.org/doc/secret-key_cryptography/aead/chacha20-poly1305“ libsodium实现了ChaCha20-Poly1305结构的三个版本”。前两个如下:
您描述的是“原始结构”。如您所见,原始结构支持的随机数小于IETF版本(64位与96位),并且AEAD结构也不同。
我的猜测:“原始结构”是在编写IETF RFC之前开发的。 libsodium基于https://en.wikipedia.org/wiki/NaCl_(software),该版本最初于2008年发布。IETFRFC于2015年编写。