doueta6642 2016-09-06 10:50 采纳率: 0%
浏览 1374
已采纳

如何在Golang中使用AES256-GCM加密文件?

AES256-GCM could be implemented in go as https://gist.github.com/cannium/c167a19030f2a3c6adbb5a5174bea3ff

However, Seal method of interface cipher.AEAD has signature:

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

So for very large files, one must read all file contents into memory, which is unacceptable.

A possible way is to implement Reader/Writer interfaces on Seal and Open, but shouldn't that be solved by those block cipher "modes" of AEAD? So I wonder if this is a design mistake of golang cipher lib, or I missed something important with GCM?

  • 写回答

2条回答 默认 最新

  • dougao7801 2016-09-12 16:55
    关注

    AEADs should not be used to encrypt large amounts of data in one go. The API is designed to discourage this.

    Encrypting large amounts of data in a single operation means that a) either all the data has to be held in memory or b) the API has to operate in a streaming fashion, by returning unauthenticated plaintext.

    Returning unauthenticated data is dangerous it's not hard to find people on the internet suggesting things like gpg -d your_archive.tgz.gpg | tar xzbecause the gpg command also provides a streaming interface.

    With constructions like AES-GCM it's, of course, very easy to manipulate the plaintext at will if the application doesn't authenticate it before processing. Even if the application is careful not to "release" plaintext to the UI until the authenticity has been established, a streaming design exposes more program attack surface.

    By normalising large ciphertexts and thus streaming APIs, the next protocol that comes along is more likely to use them without realising the issues and thus the problem persists.

    Preferably, plaintext inputs would be chunked into reasonably large parts (say 16KiB) and encrypted separately. The chunks only need to be large enough that the overhead from the additional authenticators is negligible. With such a design, large messages can be incrementally processed without having to deal with unauthenticated plaintext, and AEAD APIs can be safer. (Not to mention that larger messages can be processed since AES-GCM, for one, has a 64GiB limit for a single plaintext.)

    Some thought is needed to ensure that the chunks are in the correct order, i.e. by counting nonces, that the first chunk should be first, i.e. by starting the nonce at zero, and that the last chunk should be last, i.e. by appending an empty, terminator chunk with special additional data. But that's not hard.

    For an example, see the chunking used in miniLock.

    Even with such a design it's still the case that an attacker can cause the message to be detectably truncated. If you want to aim higher, an all-or-nothing transform can be used, although that requires two passes over the input and isn't always viable.

    本回答被题主选为最佳回答 , 对您是否有帮助呢?
    评论
查看更多回答(1条)

报告相同问题?

悬赏问题

  • ¥20 收一个快手协议下单算法
  • ¥15 求一个图片中的成交量选股公式
  • ¥15 已知正方形内随机生成坐标matlab
  • ¥30 关于#python#的问题:我想要的是这79个大特征对于房屋售价的最大的影响前十名(相关搜索:随机森林)
  • ¥15 使用matlab计算自定义特殊函数的二重积分,改变积分顺序所得的结果不同的问题?
  • ¥15 mysql做碎片化处理老是报错怎么办
  • ¥15 如何正确在vs2010中初始化map对象
  • ¥30 mmdet3d模型部署问题
  • ¥15 comsol仿真反射率、吸收率时峰值位置和深度不对!
  • ¥30 Visual Studio找不到sdk,如何解决?