What's a little surprising is that during the stopgap years, nobody adopted the bandaid of "RC4 but skip the first X bytes". That's been a known and reasonable workaround since AES was standardized.
While it is weird that nobody ever pushed for RC4-skip-1024, it wouldn't have actually fixed anything; the Fluhrer-McGrew biases recur throughout the whole keystream, have been known for many many years, and turn out to be the more efficient attack vector anyways.
Oh. I was under the impression it still made the TLS attacks harder. Not impossible, but requiring even more traffic. So you're saying no effect, as opposed to not enough effect? Just for clarity.
The attack on the RC4 biases (both kinds) is very simple: it just involves collecting samples and using basic statistics to predict the most likely keystream byte.
Because the Fluhrer-McGrew digraph biases recur through the keystream, successive samples don't require a TLS session setup and key exchange; you can reuse a single session to collect many samples. So, while the digraph biases provide a weaker signal, the attack on them actually runs faster.
Net-net, from what we know now, RC4-drop-1024 would have had no effect at all on the security of TLS. That could change, but when I look at the digraph biases, I think it's the digraph biases that are going to get more effective.
