我有一些大文件想在通过网络发送或保存到磁盘之前进行 AES 加密。虽然 encrypt streams 似乎可行，好像有warnings反对doing this相反，人们建议将文件分成 block 并使用 GCM 或 crypto/nacl/secretbox。

Processing streams of data is more difficult due to the authenticity requirement. We can’t encrypt-then-MAC: by it’s nature, we usually don’t know the size of a stream. We can’t send the MAC after the stream is complete, as that usually is indicated by the stream being closed. We can’t decrypt a stream on the fly, because we have to see the entire ciphertext in order to check the MAC. Attempting to secure a stream adds enormous complexity to the problem, with no good answers. The solution is to break the stream into discrete chunks, and treat them as messages.

• https://leanpub.com/gocrypto/read

Files are segmented into 4KiB blocks. Each block gets a fresh random 128 bit IV each time it is modified. A 128-bit authentication tag (GHASH) protects each block from modifications.

• https://nuetzlich.net/gocryptfs/forward_mode_crypto/

If a large amount of data is decrypted it is not always possible to buffer all decrypted data until the authentication tag is verified. Splitting the data into small chunks fixes the problem of deferred authentication checks but introduces a new one. The chunks can be reordered... ...because every chunk is encrypted separately. Therefore the order of the chunks must be encoded somehow into the chunks itself to be able to detect rearranging any number of chunks.

• https://github.com/minio/sio

有实际密码学经验的人能指出我正确的方向吗？

更新

我在问了这个问题后意识到，根本无法将整个字节流放入内存(加密 10GB 文件)和字节流 也是是未知长度之间存在差异可以持续很长时间，无需对流的开始进行解码(24 小时实时视频流)。

我最感兴趣的是在需要解码开始之前可以到达流末尾的大 blob。换句话说，加密不需要将整个明文/密文同时加载到内存中。

最佳答案

正如您在研究中已经发现的那样，对于大文件的身份验证加密并没有什么优雅的解决方案。

传统上有两种方法可以解决这个问题:

• 将文件分割成 block ，单独加密每个 block ，并让每个 block 有自己的身份验证标签。 AES-GCM 将是为此使用的最佳模式。此方法会导致文件大小与文件大小成比例地膨胀。您还需要为每个 block 设置一个唯一的随机数。您还需要一种方法来指示 block 开始/结束的位置。

• 使用带有缓冲区的 AES-CTR 进行加密，在 HMAC 上为每个加密数据缓冲区调用 Hash.Write。这样做的好处是可以一次性完成加密。缺点是解密需要一次通过来验证 HMAC，然后再通过另一次来实际解密。这里的好处是文件大小保持不变，加上大约 48 个字节左右的 IV 和 HMAC 结果。

两者都不理想，但对于非常大的文件(约 2GB 或更大)，可能首选第二个选项。

我已经使用下面的第二种方法在 Go 中包含了一个加密示例。在这种情况下，最后 48 个字节是 IV(16 个字节)和 HMAC 的结果(32 个字节)。还要注意 IV 的 HMACing。

const BUFFER_SIZE int = 4096
const IV_SIZE int = 16

func encrypt(filePathIn, filePathOut string, keyAes, keyHmac []byte) error {
    inFile, err := os.Open(filePathIn)
    if err != nil { return err }
    defer inFile.Close()

    outFile, err := os.Create(filePathOut)
    if err != nil { return err }
    defer outFile.Close()

    iv := make([]byte, IV_SIZE)
    _, err = rand.Read(iv)
    if err != nil { return err }

    aes, err := aes.NewCipher(keyAes)
    if err != nil { return err }

    ctr := cipher.NewCTR(aes, iv)
    hmac := hmac.New(sha256.New, keyHmac)

    buf := make([]byte, BUFFER_SIZE)
    for {
        n, err := inFile.Read(buf)
        if err != nil && err != io.EOF { return err }

        outBuf := make([]byte, n)
        ctr.XORKeyStream(outBuf, buf[:n])
        hmac.Write(outBuf)
        outFile.Write(outBuf)

        if err == io.EOF { break }
    }

    outFile.Write(iv)
    hmac.Write(iv)
    outFile.Write(hmac.Sum(nil))

    return nil
}

关于go - 你如何在 Go 中加密大文件/字节流？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/49546567/