On Wed, 2005-06-01 at 15:48, Sam Hartman wrote:
That's what I thought too. However that seems to be false. The one
reference currently in the security considerations section is for an
attack to distinguish an RC4 stream from a random stream.
A critical parameter to such attacks is the amount of keystream required
under a single key before the attack becomes feasible.
Assuming I've read it correctly, the most recent paper I've found on the
topic mentions a threshold of 2^24 bytes if you don't discard the start
of the keystream, and 2^32 if you discard the first 256 bytes.
As the sshv2 protocol allows for either party to trigger a rekey of both
directions of the communication, it certainly seems like a cautionary
note to set rekey thresholds appropriately would be in order. given the
extremely lightweight nature of the algorithm you may still come out
ahead from a cpu time/power/battery-life perspective even with frequent
Ietf mailing list