AES-GCM:解密前的验证

Question

我在看ChaCha20Poly1305 WolfSSL。需要注意的是，ChaCha20Poly1305结构具有该属性，如果验证成功，它只输出明文。

我在问自己，AES-GCM是否也能提供这个属性(从安全的角度来看非常重要)。但是，当查看GCM的模式图时，似乎是使用来自每个密文块的信息来依次计算身份验证标记。因此，密码必须解密才能验证其完整性？

Answer 1

因此，密码必须解密才能验证其完整性？

不，没有这样的要求。正如您所述，身份验证标记是从密文块中计算出来的，然而，接收方不需要解密任何东西就可以得到密文块的值--它们直接获得这些值。

让您感到困惑的是，图表是加密过程中发生的过程，而不是解密过程。

对于GCM解密，身份验证块是这样验证的:您接受密文(和AAD)，反复执行MULTH和添加1操作，然后您将MULTH和添加AAD/密文连，然后是一个MULTH并添加已处理的nonce。不需要解密密文。

1：我说"ADD“，尽管它实际上是XOR；我们使用的是GF(2^{128})，所以字段添加是xor。

Answer 2

GCM模式下的ChaCha20 / Poly1305结构和AES的工作方式基本相同。首先，AAD是MAC编辑的，然后是密文，结果是认证标签.但是，由于密文本身是首先生成的，因此不需要在解密之前验证身份验证标记。您可以只执行流解密，而无需查看任何身份验证标记。

至于实现，可以做出几种选择(重点是加密部分)：

1. 在单个方法调用中执行验证和释放明文；
2. 更新和缓冲明文，并在验证身份验证标记的最后调用期间释放它；
3. 允许在线加密/解密属性，在验证身份验证标记之前释放明文。

就我个人而言，我赞成至少向开发人员提供选项3，因为直接将明文流到文件而不是将其保存在内存中是有用的。它还允许开发人员将密文的缓冲区重用为明文(加密期间反之亦然)。

出于类似的原因，我总是将nonce、AD、密文和标记作为这种低级功能的独立输入值。一些库(例如Java )包含带有密文的身份验证标记(似乎主要是为了与不产生密码文本的模式向后兼容)，这使得缓冲/调整大小和重用数组变得更加麻烦。如果使用单独的身份验证标记实现完全在线加密/解密，则我尝试并成功地减少了30%的代码(并且由于加密/解密方法之间的对称性，复杂度降低了很多)。

当然，这是危险的，因为开发人员可以在验证之前使用明文，所以我通常会在文档中发布有关这方面的警告。密码学有很多陷阱，而且我没有看到任何人在这个特殊的坑里消失。另一方面，在Java社区中有很多关于这方面的内容，例如，当与CipherInputStream和CipherOutputStream相结合时。

然后，可以创建选项1，作为一种更安全的方便方法。当然，如果您有选项2或选项3，那么开发人员自己创建这样的方法相对容易，如果发现缺少该功能，我建议您这样做。

Java有点特殊，因为API基本上提供了增量更新和验证身份验证标记的final方法。认证标签存在于密文中。这意味着它不能执行完全在线解密，因为在更新方法期间接收的密文可能包括身份验证标记。因此，它将从“窗口”将明文从提供的密文中返回到缓冲器中，缓冲区延迟16个字节(如果使用最大标记大小)。

这也意味着认证密码的加密和解密没有对称性:加密可以在线执行，而解密则滞后。如前所述，这可能是因为开发人员除了现有的密码模式之外，还希望将AEAD密码作为一种下降方式。

要显示您可以在不验证标记的情况下解密GCM密文，请查看我的Java实现这里。