问对于AES-GCM文件加密，我应该分块还是不块？

EN

对于文件加密，流密文或使用文件的内存映射是有意义的。缓冲整个文件绝对不是做事情的方法。

如果您想使用并行化，那么您需要将文件分割成块并分别加密/解密。不过，这将为每个加密块提供身份验证标记(可能是非you )。因此，您可以扩展您的文件，例如每块28字节，而不是每个文件28字节。您可能还需要一个单独的文件特定密钥(如果需要的话，可以从主键派生)。

它也是实际执行在线加密和解密为GCM。您甚至可以分割整个文件的加密和标记创建以及验证和解密，以便它们可以并行执行。当然，后者将意味着在验证实际执行之前不应该使用解密文件。

现在，将密文分割成块很容易，只要您看到它们只是CTR加密的明文块。将密文的单独GMAC组合在一起要困难得多，需要模幂运算。

最好先用GCM加密文件，然后将密文和明文以块的形式传送。最好使用一个API，其中身份验证标记被认为独立于明文(即提供上面提到的在线属性)。

Python在密码方面不是很快；它主要要求使用基于C的库来顺利地执行加密。我建议，对于诸如文件加密之类的低级函数，在这种功能方面，C实际上比Python要好得多(而且在这种用法上，C远远优于Java --我最喜欢的语言--以防您认为我有偏见)。

如果您正在处理大小为64 GB甚至更小的文本文件，我相信您应该立即对文件块并开始加密。这是你前面提到的前一种选择。

使用GCM类似CBC的原因是，GCM可以并行运行，而同样安全的CBC不能并行运行。如果您“浪费”cpu在等待文件加载到内存时开始加密的能力，那么它的效率就会降低。GCM是一种使用“指令级并行性”来表示维基百科页面的算法。

您应该让程序开始加载文件，开始加密前128位部分，并继续直到整个文档被加密。

Python密码学文档和密码穹顶文档

AES GCM是AES在计数器模式下的一个版本，计数器模式将块密码转换为流密码。流密码的主要优点是我们不必担心填充。每次调用AES加密函数时，得到16字节的伪随机密钥流，该函数与明文进行异或编辑，得到相应的密文。当使用C、C++或Python等编程语言读取文件时，您可以指定要读取的字节数，同时循环直到文件结束。在这种情况下，最好选择16的倍数，比如1024*1024字节或更多字节，但要考虑到硬件的限制和效率。为每个循环交互读取16个字节是效率低下的。您可以通过尝试和错误以及一些基准来找到最优的读取值。还可以检查这些编程语言提供的这些函数成功读取的字节数(让它称为x)。在Python的例子中：

# This is only for illustrative purposes!

MY_BLOCK_SIZE = 1024*1024

with open(filename, "rb") as fobj:
     run = True
     while run:
         data = fobj.read(MY_BLOCK_SIZE)
         x = len(data)
         if x == 0:       
               break
         elif (x%MY_BLOCK_SIZE) == 0:
              #invoke AES encryption function MY_BLOCK_SIZE/16 times incrementing the counter each time
             # do all the things for calculating the authentication tag
              # Ciphertext is XOR(data, key_stream, len(data))
         else:
             #invoke AES encryption function MY_BLOCK_SIZE/16 times incrementing the counter each time # do all the things for calculating the authentication  # Ciphertext is XOR(data, key_stream, len(data))

假设以字节块(倍数为16 )读取任意长度的文件，有两种可能，最后一次读取的块大小可能正好是您的块大小(x = 16*n)或小于它(x < 16*n)。在这两种情况下，您都必须调用AES加密函数n时间，为每个n递增计数器，但您只使用为该迭代生成的密钥流的x字节来使用明文进行XOR。