encryption - 使 GCM/CBC 密码在 golang 中流式传输

Question

Go 中的 GCM 和 CBC AES 密码不能与 StreamWriter 或 StreamReader 一起使用，这迫使我将整个文件分配到内存中。显然，这对于大文件来说并不理想。

我正在考虑通过将一些固定大小的 block 分配到内存中并将它们提供给 GCM 或 CBC 来使它们可流式传输，但我认为这可能是个坏主意，因为它们必须有一个原因就是这样设计的。

有人可以解释为什么不将整个文件分配到内存中就不能使用这些操作模式吗？

Answer 1

简单的答案 - 这就是他们设计 API 的方式。

CBC 和 GCM 是非常不同的模式。 GCM 是 AEAD 模式(带关联数据的身份验证加密)。你真的需要身份验证吗？如果不是，对于大文件，CBC 是一个不错的选择。您也可以使用 CTR 或 OFB，但它们是流式传输模式并且对选择 IV 非常严格。

在执行任何操作之前，我建议您阅读这些模式。您至少必须了解它们需要哪些参数、用于什么目的以及应如何生成它们。

加拿大广播公司

BlockMode 接口(interface)非常适合加密大文件。您只需要逐 block 加密。 CBC 需要填充，但 Go 没有实现。至少，我没有看到一个。你将不得不以某种方式处理它。

GCM

GCM 使用AEAD 接口(interface)，它只允许您加密和解密整个消息。绝对没有理由这样实现。 GCM是streaming mode，其实很适合streaming encryption。唯一的问题是身份验证。 GCM 在末尾生成一个标记，其作用类似于 MAC。要使用该标签，您不能只加密无穷无尽的数据流。您必须将它分成 block 并分别对它们进行身份验证。或者做其他事情，但在某些时候您必须读取该标签并验证它，否则使用 GCM 毫无意义。

一些库(包括 Go)所做的是，它们在加密时隐式地在末尾附加该标记，并在解密时读取和验证它。就个人而言，我认为这是一个非常糟糕的设计。标签应该作为一个单独的实体提供，你不能假设它总是在最后。这并不是 Go 实现中的唯一问题。对不起，咆哮。最近我处理了一个特别糟糕的实现。

作为一种解决方案，我建议您将流分成 block 并使用唯一的随机数分别加密它们(这非常重要)。每个 block 的末尾都有一个标签，您应该验证该标签。这样您就可以使用 GCM 身份验证。是的，这有点丑陋，但 Go 不允许您访问内部方法，因此您可以制作自己的加密 API。

作为替代方案，您可以找到不同的实现方式。甚至是 C 库。我可以建议 mbedtls。对我来说，这是我在 API 方面遇到的最佳实现。