默认情况下,GPG 在加密期间压缩文本。
此外,RFC 4880说:
2.3. 压缩
OpenPGP 实现应该在应用签名之后但在加密之前压缩消息。
我们知道加密不会试图隐藏数据长度,并且在某些情况下,此属性使可以执行有限选择明文攻击的攻击者有可能了解有关完整明文的更多信息(参见CRIME、BREACH等。 )。
一行执行摘要是您不得压缩。
OpenPGP 实现默认压缩消息是否安全?禁用此行为是否有意义?
默认情况下,GPG 在加密期间压缩文本。
此外,RFC 4880说:
2.3. 压缩
OpenPGP 实现应该在应用签名之后但在加密之前压缩消息。
我们知道加密不会试图隐藏数据长度,并且在某些情况下,此属性使可以执行有限选择明文攻击的攻击者有可能了解有关完整明文的更多信息(参见CRIME、BREACH等。 )。
一行执行摘要是您不得压缩。
OpenPGP 实现默认压缩消息是否安全?禁用此行为是否有意义?
加密泄漏数据长度:对于任何给定的输入消息,加密输出的长度将接近输入消息的长度。如果使用无填充加密模式(如 CFB,在PGP 实现的 OpenPGP 格式中使用),则可以准确恢复明文数据长度。这是所有加密系统共有的属性,也是流量分析成为强大攻击工具的原因。
压缩不会从质量上改变这个问题,但它会使它变得更糟。压缩使数据长度依赖于数据内容,因此它可以泄漏额外的信息。例如,考虑某个网站的支付系统:客户将他的信用卡信息发送到该网站,然后该网站将信用卡号、转账金额和当前日期转发给合作银行。假设每个这样的消息都将使用 OpenPGP 加密,并且具有固定长度的格式(信用卡号为 16 个字符,依此类推)。固定长度旨在阻止流量分析。然而,启用压缩时,情况并非如此:如果金额或当前日期包含在信用卡号中也可以找到的数字模式,则消息会更短。攻击者知道当前日期,并且可以推断出转账金额(它必须与网站上出售的其中一件商品的价格相匹配),因此可以利用泄漏来获取信用卡号的部分信息。
这完全取决于上下文。Web 和 HTTPS 提供了一些使利用非常有效的特性:
多亏了这些特性,CRIME 才有效(好吧,现在已经不行了,因为浏览器不支持 TLS 级别的压缩,但它曾经可以工作)。但它们不适用于通常的OpenPGP 使用上下文。PGP 是为电子邮件而设计的,每条消息都需要一个人痛苦地输入,而另一端则是另一个人阅读它们。没有恶意代码,没有或很少选择明文,以及围绕秘密值移动的人类语言的模糊性。
因此,我们可以说 PGP 的正常使用场景是压缩不会显着降低安全性,这证明了默认使用它是合理的。虽然,公平地说,PGP 默认不压缩,因为它通常是安全的;它默认压缩是因为它在 20 年前就是这样做的,而且旧习惯很难改掉。一开始,压缩是为了弥补加密的开销,主要是非对称加密的额外几百字节,以及 Base64 编码所暗示的 +33% 的大小增加。对于最近的硬件和网络,这几乎无关紧要。PGP 比其他任何东西都更能摆脱传统的压缩。
总而言之,一个启发性的故事。1942年初,美国海军正努力为日本在珍珠港和珊瑚海海战之后的下一次袭击做准备。该目标在日本通讯中以代号为人所知。为了确认其身份,美国人故意在常规消息的正常传输中发送虚假消息,以便看到该信息出现在日本流中并与之关联。在这个具体案例中,他们声称他们在中途岛的基地有一个坏了的蒸馏器。日本的编码传输报告说,下一次攻击的目标是缺水。这一关键信息对日本的失败起到了重要作用,之后日本的一切都走下坡路,直到二战结束。(甚至维基百科有关于这个轶事的指针,所以它不仅是一个很好的故事,而且它甚至可能是真的。)
这是一个选择明文攻击,加上流量分析。对于目前的讨论,重要的一点是常规消息类似于计算机:尽管是在 1942 年,但军事行为可以被认为是模拟无意识的计算机。选择明文攻击可以被取消,因为它发生在受害者(这里是日本通信网络)可以可靠地以可预测的格式在其自己的编码系统中中继所选信息的环境中。
这同样适用于 PGP。如果您以传统方式使用 PGP,用于手工制作的文本消息,从人脑到另一个人的大脑进行通信,那么压缩是安全的。如果您以自动方式使用 PGP,以可预测的格式发送大量消息,其中的内容大多可以被攻击者猜到甚至选择,那么压缩可能会大大增加您的安全问题。
如果攻击者可以欺骗您一遍又一遍地重复加密(并因此压缩)几乎相同的明文,那么我怀疑这种攻击可能是可能的,但进入这种情况似乎不太可能。(您需要将攻击者机密的内容和攻击者控制的内容结合起来的明文。)
BEAST 和 CRIME 都特别依赖于 Web 浏览器和 TLS 的属性。BEAST 与压缩无关,但与 CBC 模式加密和猜测明文的第一个块有关,这是可行的,因为 HTTP 请求相当可预测,并且因为 TLS 1.0 使用可预测的 IV。(另一方面,GPG 使用适当随机化的 IV。)犯罪基于使用 JavaScript 重复发出类似的请求并查看压缩如何更改输出(如您所指出的),但需要大量请求和被动攻击者观察压缩请求。
因此,如果您不以自动化方式使用 GPG,我看不出像 CRIME 这样的攻击如何可能扩展到 GPG。即使可以,这也只是一种明文恢复攻击,因此您需要一种情况,即攻击者可以自动将其有效负载注入其他秘密明文并让您对其进行加密。
对于给定的可能文件格式,可以非常一致地推断出消息的压缩率。这允许攻击者猜测明文有多大。此大小信息可用于推断其他信息 - 例如,机密医学检测结果是阳性(大量咨询、辅助图表和“下一页”页面)还是阴性(较小的文件)。
填充解决了这个问题,但据我所知,GPG/PGP 不包括自动伪随机字节填充选项。所以你需要在填充和不压缩,或者压缩和不填充之间进行选择;因为零字节填充的压缩会折叠填充。
压缩 PGP 明文的想法的可能安全起源是使已知明文攻击更难执行 - 尽管如果您的密码算法不能直接防止已知明文攻击,那么您就会遇到 90 年代压缩的问题明文解决不了。
非安全原因很简单——你不能压缩密文来减少带宽和存储,因为它太随机了。
所以回答“安全吗?” :是的,如果您不关心推断的文件大小或可以预先用 RNG 填充明文。
除了提供有关消息大小的信息外,压缩格式通常具有可以帮助分析人员的固定标头。例如,RFC 1952 [1] 中描述的 Gzip 文件格式的前三个字节是恒定的,在某些情况下可以很容易地猜到后面的七个字节(标志和时间戳)。作为另一个例子,[2] 中描述的 bzip2 格式的前 14 个字节具有非常低的熵(2+6 个字节具有恒定值,4 字节 CRC,其余 2 个字节最多可以假设 18 个值)。