问哪种流密码可以替代SSL中的RC4？

EN

据我所知，RC4并不像我们所希望的那样安全，而且被认为是对付TLS1.0上猛兽攻击的临时后备解决方案。

我知道谷歌在其大多数服务中都使用RC4，这也是人们不应该一直打开gmail的原因；

我认为它必须被AES-128-256取代。而TLS 1.1支持这样的模式，我们只需要等待越来越多的服务器/浏览器开始支持它。

我希望看到ECDH-RSA2K-ECE256-GCM在不久的将来得到广泛应用。

有几种方法可以回答你的问题：

1. 您不能在SSL中“替换”RC4。SSL是一个标准协议，只有当客户机和服务器都支持并同意使用它时，才能使用任何算法。因此，在实践中，除非您同时控制客户端和服务器代码，否则无法按您的意愿替换算法；即使这样，它也不再是“标准SSL (实际上称为TLS)”，而是一个自定义变体。
2. 如果我们想要定义一个TLS变体，那么我们可以定义新的密码套件，它使用不同于RC4的流密码。这份工作有一些不错的人选，尤其是电子表格投资组合：这些算法确实得到了公平的分析，而且“看上去很强大”。与RC4相反，它们中没有已知的可检测偏倚。它们也恰好要快得多。
3. 标准TLS现在定义了GCM密码套件。GCM是一种基于128个比特块的分组密码(通常是AES)的运算模式；该块密码用于CTR模式，实际上将其转化为流密码。因此，我们可以说，使用基于GCM的密码套件实际上正在用另一个“流密码”取代RC4。

请注意，SSL/TLS不仅确保机密性，而且确保完整性；因此，必须在某个地方有一个MAC。当使用RC4进行流密码时，MAC是带有散列函数(MD5或SHA-1)的HMAC。如果你用一个只进行加密的超快流密码代替RC4，那么HMAC可能成为瓶颈。GCM将分组密码用于加密和MAC，因此快速分组密码实际上加快了整个过程。在现代x86处理器上，有一个AES的硬件支持，它包含一个特别适合GCM的操作码。在较小的体系结构上，性能问题实际上更有可能发生，GCM并不一定是一个好的选择( GCM中二进制字段乘法的“快速”实现使用大表，这些表在CPU上的小L1缓存不太快)。