如何在 golang 中使用 AES256-GCM 加密文件？

Question

AES256-GCM 可以在https://gist.github.com/cannium/c167a19030f2a3c6adbb5a5174bea3ff中实现

但是，Seal接口的方法cipher.AEAD有签名：

Seal(dst, nonce, plaintext, additionalData []byte) []byte

所以对于非常大的文件，必须将所有文件内容读入内存，这是不可接受的。

一种可能的方法是在and上实现Reader/Writer接口，但这不应该由 AEAD 的那些分组密码“模式”来解决吗？所以我想知道这是golang cipher lib的设计错误，还是我错过了GCM的一些重要内容？SealOpen

Answer 1

AEAD 不应用于一次性加密大量数据。API 旨在阻止这种情况。在单个操作中加密大量数据意味着 a) 所有数据都必须保存在内存中，或者 b) API 必须通过返回未经身份验证的明文以流方式操作。返回未经身份验证的数据很危险，因为 gpg 命令还提供了流接口，所以在互联网上不难找到人们提出的建议。gpg -d your_archive.tgz.gpg | tar xz当然，使用 AES-GCM 之类的结构，如果应用程序在处理之前未对其进行身份验证，则可以很容易地随意操作明文。即使应用程序在确定真实性之前小心翼翼地不向 UI“释放”明文，流式设计也会暴露更多的程序攻击面。通过规范化大密文并因此流式传输 API，出现的下一个协议更有可能在没有意识到问题的情况下使用它们，因此问题仍然存在。最好将明文输入分成相当大的部分（比如 16KiB）并单独加密。这些块只需要足够大，以使额外验证器的开销可以忽略不计。通过这样的设计，可以增量处理大消息，而不必处理未经身份验证的明文，并且 AEAD API 可以更安全。（更不用说可以处理更大的消息，因为 AES-GCM 对单个明文有 64GiB 的限制。）需要一些想法来确保块的顺序正确，即通过计算随机数，第一个块应该是第一个，即从零开始随机数，最后一个块应该是最后一个，即通过附加一个空, 带有特殊附加数据的终结符块。但这并不难。例如，请参阅miniLock中使用的分块。即使采用这样的设计，攻击者仍然可以导致消息被可检测地截断。如果您想瞄准更高，可以使用全有或全无变换，尽管这需要两次通过输入并且并不总是可行的。

Answer 2

这不是设计错误。只是在这方面 API 是不完整的。GCM 是一种流操作模式，因此能够在不停止流的情况下按需处理加密和解密。看来您无法重用与之前的 MAC 状态相同的 AEAD 实例，因此您无法直接使用此 API 进行 GCM 加密。crypto.NewCTR您可以在您自己的 GHASH之上实现您自己的 GCM 。