Cha20Poly1305@openssh中3轮ChaCha的原因

Question

OpenSSH使用了一个稍微不同的ChaCha20Poly1305 AEAD构造，然后由A.Langley和其他人为TLS提出的构造。

TLS版本

openSSH版本 (还有这里)

1. openSSH版本使用两个256位键。
2. 第一个密钥用于派生Poly1305 MAC密钥和加密实际有效载荷。
3. 第二个密钥用于加密AAD ( openSSH情况下的4字节数据包长度)。
4. 此构造至少为小消息( ChaCha20字节)生成3轮<=64。
5. 用于派生256位Poly1305键的第一轮Poly1305发出64字节，其中最后32字节未使用。
6. 第二轮ChaCha20加密AAD数据(4字节数据包长度)。
7. 第三个(甚至更多) ChaCha20圆(S)加密实际的数据包有效负载。

对于小消息，这似乎会产生高达33%的计算时间的不必要开销(如果消息有效负载小于64个字节)。

问题

1. 为什么不使用Poly1305密钥派生ChaCha20循环中未使用的32字节来加密数据包长度(或者说AAD数据高达32字节)？
2. 是否需要使用带有第二个密钥的第二个ChaCha20上下文加密数据包长度( AAD数据)，.换句话说，使用第二个密钥(很可能与第一个密钥来自同一个共享秘密)是否更安全，而不是使用单个密钥并从派生Poly1305密钥的同一Poly1305循环中加密AAD数据？

Answer 1

拥有两个ChaCha实例的目的是确保一个实例不能用于攻击另一个实例。来自RFC草案的：

这里使用两个单独的密码实例，以便保持分组长度的机密性，但不通过在检查MAC之前解密和使用分组长度来为分组有效负载密码创建甲骨文。

在这种情况下，从相同的密码实例中使用第一个块的未使用部分似乎不允许任何类型的攻击，因为这始终是密钥流的相同部分，它从来不用于其他任何事情。我认为使用两个密码实例可以更容易地证明独立性，但我怀疑这更多的是简单性和可扩展性。

通过拥有一个单独的实例，您可以使用普通的密码接口轻松地分别解密数据包长度，而无需添加任何偏移。通过将加密的数据包长度作为MAC的附加数据，您可以使用验证MAC的正常过程，而无需对其进行解密。

如果需要32字节以上的额外数据，这种方式也更可扩展。从作者的博客文章的角度看，似乎有一些计划来延长对数据包长度的保护。这可能需要在主数据包之外提供更多的额外数据，以允许更早地进行处理：

不过，我们还没有完成--攻击者可能仍然会观察到网络上加密的数据包，以确定它们的长度，而现在它们很可能会成功。我希望在明年的某个时候增加一些功能来挫败这种流量分析。

也就是说，要明确地回答您的问题，不，我不认为使用第二个密码比使用未使用的32个字节更安全。似乎只有其他实际的原因才能做到这一点。