AEAD 不应用于一次性加密大量数据。API 旨在阻止这种情况。
在单个操作中加密大量数据意味着 a) 所有数据都必须保存在内存中,或者 b) API 必须通过返回未经身份验证的明文以流方式操作。
gpg -d your_archive.tgz.gpg | tar xz
当然,使用 AES-GCM 之类的结构,如果应用程序在处理之前未对其进行身份验证,则可以很容易地随意操作明文。即使应用程序在确定真实性之前小心翼翼地不向 UI“释放”明文,流式设计也会暴露更多的程序攻击面。
通过规范化大密文并因此流式传输 API,出现的下一个协议更有可能在没有意识到问题的情况下使用它们,因此问题仍然存在。
最好将明文输入分成相当大的部分(比如 16KiB)并单独加密。这些块只需要足够大,以使额外验证器的开销可以忽略不计。通过这样的设计,可以增量处理大消息,而不必处理未经身份验证的明文,并且 AEAD API 可以更安全。(更不用说可以处理更大的消息,因为 AES-GCM 对单个明文有 64GiB 的限制。)
需要一些想法来确保块的顺序正确,即通过计算随机数,第一个块应该是第一个,即从零开始随机数,最后一个块应该是最后一个,即通过附加一个空, 带有特殊附加数据的终结符块。但这并不难。
例如,请参阅miniLock中使用的分块。
即使采用这样的设计,攻击者仍然可以导致消息被可检测地截断。如果您想瞄准更高,可以使用全有或全无变换,尽管这需要两次通过输入并且并不总是可行的。