正如Matthew Green 所说，这种攻击“正处于可行性的边缘”。它在概念上适用于任何使用 RC4 的协议，尽管有些协议比其他协议更容易受到攻击。

RC4 的弱点是输出的第一个字节有偏差。从密钥中，RC4 生成一个长的伪随机字节流，而加密只是对要与该流加密的数据进行逐字节异或。因此，当相同的数据被多次加密（每次使用不同的密钥）时，RC4 输出中的偏差会转化为机密数据的恢复。例如，假设输出的第 17 个字节的值 0x42 比其他 255 个可能的字节值更频繁（一个虚构的说明性数字）。由于同一条消息被反复加密，它的第 17 个字节（我们称它为x) 将与 RC4 输出的第 17 个字节进行异或运算。攻击者观察所有加密消息，可能会注意到输出的第 17 个字节比任何其他值更常见的是 0x7C。然后，攻击者将推断观察值 0x7C 对应于 RC4 输出的第 17 个字节为 0x42 的情况。然后他将得出结论x XOR 0x42 = 0x7C，即x = 0x3E。攻击者刚刚恢复了一个字节的明文。

重要的一点是，只有 RC4 输出的第一个字节具有可以在“合理”时间内利用的偏差。偏差仍然很小；要可靠地观察到这种偏差，需要数百万次观察到的加密，所有这些加密都具有相同的秘密数据。

在 Web 设置（使用 HTTPS）中，攻击如下所示：

• 受害者的浏览器知道一个 cookie 可以解锁某个站点上的会话（我们称之为www.example.com. 攻击者想要那个 cookie。
• 攻击者控制受害者的网络上下文。实际上，攻击者在公共场所运行一个 WiFi 接入点，并且受害者连接到它，认为 AP 是由他决定花费几个小时的餐厅或图书馆提供的。
• 攻击者在响应从浏览器到某个站点（不是 HTTPS）的 HTTP（不是 HTTPS）请求时注入了一些恶意的 Javascript www.example.com。该 Javascript 将反复触发对 的 HTTP GET 调用https://www.example.com，例如通过<img>在网页中创建隐藏标签。
• 由恶意 Javascript 触发的每个调用都意味着一个 SSL/TLS 连接，其中包含 cookie，位于可预测的位置。攻击者还在调用后向连接中注入一个 RST 数据包，以强制关闭连接，从而每次都使用新的握手和新的 RC4 密钥建立新的连接。

实际上，攻击者不能真正希望超过每秒十个左右的连接，因此一百万个呼叫将花费超过一整天的时间。此外，所有这些连接都会到达目标站点 ( www.example.com)，这可能会引发一些警报。如果攻击者可以全速攻击 30 小时左右，那么他将能够猜测一个或几个 cookie 字节（出现在流中 RC4 偏差最重要的位置的字节）。

结论是，这种攻击确实处于可行性的边缘：它可以在实验室条件下进行演示，但尚未在野外被发现。然而。

对于 WPA/TKIP，可以应用相同的原理，但更实用，因为在该协议中，每个单独的数据包都有自己的 RC4 流，并使用特定于数据包的密钥重新开始。收集一百万个数据包肯定比使用 TLS 握手观察一百万个 TCP 连接更容易。但是，弱点绝不限于该单一协议。它与 RC4 是同质的，并将遵循它进入任何使用 RC4 的协议。

需要注意的是，SSH 使用 RC4 时，通常是以“arcfour128”或“arcfour256”的名义进行的；在这两种情况下，这是 RC4，但前 1536 个字节的输出被丢弃。这些是具有最大偏差的字节。因此，这些 RC4 变体比普通的 RC4（在 SSH 术语中称为“arcfour”）要强大得多。

对于新的协议设计，不要使用 RC4。如果您真的需要超越一些“普通”的 AES/GCM，请考虑eSTREAM 产品组合中的流密码：它们比 RC4 更安全、更快。但请记住，协议设计很难。