AEAD在V2ray v3.0后加入到Shadowsocks协议,但是在v4.28后才整合到VMessAEAD协议上。因此我一直都没有用过,甚至在v4.23前都没听说过他。不过,最近因为GFW逐渐长高,看讨论区很多人说要在加上AEAD才能更加稳定上网。于是我就来研究了一下AEAD。
关于V2ray的部分写在前面:
根据Shadowrocket显示,在AlterID设置为0时,启动AEAD;否则启动MD5+AES。
AEAD在客户端启用即可,服务端不用改变AlterID值。因为服务端AlterID需要大于等于客户端值,因此如果服务端设置为0时,可以强制客户端设为0,即强制客户端启用AEAD。
根据 Cisco - An Interface and Algorithms for Authenticated Encryption,认证加密(Authenticated Encryption)是一种可以增加额外保证的纯文本加密形式,他提供了一种验证完整性和真实性的办法。Authenticated Encryption with Associated Data(AEAD),通过增加一些额外的非加密数据(关联数据),来验证完整性和真实性。
AEAD接口(2. AEAD Interface)
AEAD算法具有两个操作,即已认证的加密和已认证的解密。 这些算法的输入和输出在下面根据八位位组字符串定义。
一个实现可以接受附加的输入。 例如,可以提供输入以允许用户在不同的实施策略之间进行选择。 但是,此类扩展绝不能影响与其他实现的互操作性。
认证加密(2.1 Authenticated Encryption)
认证加密有四个输入量,每个都是八位字节串(octec string)。
- 密钥(key)K,必须(MUST)通过均匀随机或伪随机生成(uniformly random or pseudorandom)。
- 随机数(nonce)N。每个提供给Authenticated Encryption操作的不同调用(distinct invocations)的每个随机数必须(MUST)是不同的,除非每个随机数的长度均为零。产生不同随机数的程序应该(SHOULD)使用随机数格式,并且可以(MAY)用一些其他符合唯一要求(uniqueness requirement)的方法。其他应用程序应该(SHOULD)使用零长度的随机数。
- 纯文本(plaintext)P,包括要被加密和认证的数据。
- 关联数据(associated data)A,包括将要被认证但没被加密的数据。
单一输出量密文(ciphertext)C,其长度至少和明文等长,否则加密过程不能执行。
所有的输入输出都是可变长度的八位字节字符串,密钥K中的八位字节数在1到255之间。对于每个AEAD算法,K的长度必须固定。
注:甚至有一篇论文RFC2119来写关键词使用约定,真是长见识了。
认证解密(2.2 Authenticated Decryption)
经过身份验证的解密操作具有四个输入:K,N,A和C。它只有一个输出,即纯文本值P或表示输入未认证的特殊符号FAIL。当使用输入K,N,P和A通过加密操作生成C时,对于N,P和A的某些值,密文C,随机数N和关联的数据A对于密钥K是真实的。只要输入N,P和A是由不知情的,不知道秘密密钥的对手(假设AEAD算法是安全的)精心制作的,则该操作很有可能会返回FAIL。
优点(1.3 Benefits)
AEAD方法使需要密码安全服务的应用程序可以更轻松地采用这些服务。它使应用程序设计人员能够专注于安全服务,规范化和数据编组等重要问题,从而使他们无需设计满足其安全目标的加密机制,从而使应用程序设计人员受益。重要的是,可以独立于特定应用中的使用来分析AEAD算法的安全性。此属性使AEAD的用户无需考虑安全方面的问题,例如身份验证和加密的相对顺序以及密码和MAC的特定组合的安全性,例如可能通过MAC失去机密性。使用AEAD界面的应用程序设计人员无需在设计阶段选择特定的AEAD算法。另外,到AEAD的接口相对简单,因为它仅需要单个键作为输入,并且只需要单个标识符即可指示在特定情况下使用的算法。
AEAD方法通过提供可能无法减少计算量,实现成本和/或存储需求的优化来使加密算法的实现者受益。更简单的界面使测试更加容易。这对于密码算法的实现是相当可观的。通过提供访问加密服务的统一接口,AEAD方法允许单个加密实现更轻松地支持多个应用程序。例如,支持AEAD接口的硬件模块可以轻松地为使用该接口的任何应用程序提供加密加速,甚至可以为构建模块时尚未设计的应用程序提供加密加速。
参考资料: