On 2010/11/09 (Nov), at 2:59 PM, Matthew Toseland wrote: > On master, we use the hard RNG (Yarrow) to generate padding for data > packets, but not for auth packets, which use fastWeakRandom. With > anon-auth we often don't have a PeerNode object on which to put a > per-peer RNG... > > On zidel/packetFormat (the new packet format branch), for a while > fastWeakRandom was used to generate padding for packets; now it's a > per-peer weak RNG. On that branch, the crypto is dependant on the > IV, not on the packet hash, so arguably the strength of the padding > is less important, but it's still probably a bad idea to pad with > predictable data?
It looks like the current code encrypts the padding before transit anyway. If the new code does not finally encrypt the padding, then other concerns might be exposing so much direct output from the rng that it's seed becomes guessable, or using up entropy (if that is possible here). btw, do resends have "new" random padding each time? If that is case it would also not matter, b/c even a weak attacker could drop your packets and correlate them to find the precise length (and ignore the padding). -- Robert Hailey > What should we do in all these cases? We need a consistent and > thought-out policy. Security is more important than performance, and > the performance impact is relatively small even if we use Yarrow.
