第一件事:不要惊慌。不要轻举妄动,花时间思考。
今天出现的幻灯片描述了RC4中关于偏差的新结果。RC4 生成一个依赖于密钥的伪随机字节流,然后与要加密的数据进行异或运算(解密相同)。众所周知,RC4 的输出略有偏差,即某些字节值比其他字节值更可能,尤其是在输出的第一个字节中。这导致了可能的以下攻击:假设给定的秘密消息m被重复加密,每次使用不同的密钥但始终位于流中的相同位置,然后观察加密数据将允许恢复消息m。实际上,如果在位置j密钥流字节x比所有其他 255 个值更有可能,并且攻击者观察到加密字节值b更频繁地发生,然后他将猜测x = b XOR p与明文字节p,因此p = x XOR b。
通常认为,尽管 RC4具有这种偏见,但在 RC4 的实际使用中,例如SSL/TLS中,它们并不容易受到攻击。
新结果以更系统的方式为已知的结果增加了一些偏差,并给出了衡量标准。这些措施部分证实了上述立场。当然,幻灯片很容易采取世界末日的立场,并警告彻底破坏,因为:1.研究人员需要对他们的结果做一些营销和广告,以吸引资金,2.这是伯恩斯坦式风格大喊时代末日临近,其他人都错了。
数据表明,攻击需要数百万个连接才能起作用。在一个实际的 SSL/TLS 设置中,目标是一个 cookie 值,你不会每 15 秒左右打开一个新连接超过一次,因为浏览器和服务器将“保持连接活动”,所以它会一年 24/7 上网,总是在同一个站点上,总是在浏览器或服务器决定关闭当前连接之后立即变得容易受到这种攻击。因此,不要惊慌。没有理由急于深入研究密码套件设置。然而。
RC4 仍应在适当的时候逐步淘汰。事实上,偏差很小,但比之前预期的要大(“我们”认为“几百万”是“10 亿左右”)。安全边际变得非常薄。由于 BEAST 攻击,RC4 最近得到了复兴,但它已经被认为是一种临时措施。事实上,BEAST 攻击不再有效,因为找到了变通方法。
“修复” RC4 的一种方法已被多次建议,即删除前 256(或 512 或 1536 或其他)字节的输出,因为这些是其中最有偏见的(幻灯片中的图形显示相当清楚地)。但这与 RC4-as-we-know-it 不兼容,因此在 SSL/TLS 上强制这样做没有什么意义。如果必须修改 SSL 库以实现更好的算法,它们也可以使用已经标准化的算法,即GCM(有关 GCM 与 SSL/TLS 的集成,请参见RFC 5288)。这将比翻新的 RC4 更好,后者仍有其他偏差(更轻微,但仍可检测到,并且不限于输出的第一个字节)。
现在,什么都不做。但是看看谷歌会做什么。谷歌做什么,世界就会跟随。
如果您真的很担心,请立即切换回 AES/CBC(甚至 3DES/CBC),尽管 BEAST 如上所述,不再适用于最新的浏览器(如果浏览器不是最新的,那么用户有更紧迫的问题需要解决!)。
在理想情况下,这种新的攻击尽管缺乏即时适用性,但会促使供应商实施 TLS 1.2 + GCM,Web 将更加安全。