如果AES GCM (0^128)溢出并与GHASH nonce (0^128)碰撞怎么办？

Question

在GCM模式下使用AES时，GHASH函数使用E(0^128)作为H (身份验证密钥)的初始值。下铺CTR模式的IV初始化如下：

前缀(应用程序名)

这个初始计数器从...02开始，就像解释的这里一样。我猜这是为了防止与GHASH函数发生碰撞。

众所周知，让一个时间溢出是非常非常糟糕的，因为重复一个现在完全打破了GCM模式。但是，如果前缀都是零，并且计数器只溢出到0xffffff+1 (0^128)，怎么办？您将拥有一个与身份验证密钥具有相同值的xor‘’d块。这会破坏GCM吗？

Answer 1

这是不允许的。接受超过2^{39} - 256位(即2^{32} - 2块)的消息的AES-GCM实现被破坏。对于比2^{39} - 256位长的消息，使用AES-GCM定义的协议是荒谬的。

协议不应该被定义为消息那么长，因为对手可以通过发送一条长得令人发指的消息来浪费接收者的资源。如果你允许兆字节长的信息，一个对手可以浪费1TB的内存，在你意识到它是伪造的，并把它扔在地板上。

相反，您应该将消息分解为不需要在内存中缓冲的单元，然后才能决定将伪造的数据丢弃到地板上，比如IP数据包的1500个字节，TCP段的64 KB，或者如果适合您的应用程序，还需要一个兆字节。

但是让我们假设您确实有一个违反AES-GCM规则的破坏的协议，以及一个允许它发生的坏的实现。如果您这样做-加密{>}2^{32} - 2块的消息，并将计数器截断为32位并进行包装，会发生什么？然后：

1. 知道第一个明文块的对手可以解决GHASH认证密钥的问题，并且可以任意伪造多条附加消息。
2. 知道第三个明文块的对手可以解密明文的块号2^{32}。

如果计数器携带到当前，而不是被截断到32位，那么它是一种稍微不同的已知明文攻击--例如，启用对下一条消息的第一个块的解密，假设该条消息的顺序消息号，而不是同一条消息的块2^{32}。

总之，不要这么做！