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

我当时正在考虑通过将一些固定大小的块分配到内存中并将它们提供给GCM或CBC来使它们可流化，但是我认为这可能是个坏主意，因为一定有理由设计它们 办法。

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

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

CBC和GCM是非常不同的模式。 GCM是AEAD模式(具有关联数据的经过身份验证的加密)。您实际上需要身份验证吗？如果不是这样，则对于大文件，CBC非常适合。您也可以使用CTR或OFB，但它们是流模式，并且在选择IV时非常严格。

在实施任何内容之前，我建议您先阅读这些模式。您至少必须了解它们所需的参数，目的和生成方式。

哥伦比亚广播公司

BlockMode接口非常适合加密大文件。您只需要逐块加密。 CBC需要填充，但是Go没有实现。至少我看不到。您将不得不以某种方式处理该问题。

GCM

GCM使用AEAD接口，该接口仅允许您加密和解密整个消息。绝对没有理由应该这样执行它。 GCM是一种流模式，实际上非常适合流加密。唯一的问题是身份验证。 GCM在末尾产生一个标签，其作用类似于MAC。要使用该标签，您不仅可以加密无尽的数据流。您必须将其拆分为多个块并分别进行身份验证。或执行其他操作，但是在某些时候您必须阅读该标签并进行验证，否则使用GCM毫无意义。

包括Go在内的某些库的作用是，它们在加密时在末尾隐式附加该标签，并在解密时读取并验证它。我个人认为这是一个非常糟糕的设计。标签应作为一个单独的实体提供，您不能仅仅假设它总是在结尾。这不是Go实施中的唯一问题之一。
对不起，那个咆哮。最近，我处理了一个特别糟糕的实现。

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

或者，您可以找到其他实现。甚至一个C库。我可以建议mbedtls。对我来说，这是我在API方面遇到的最好的实现。

这是用于从BlockMode读取的流实现。你的旅费可能会改变。