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.
_______________________________________________
Devl mailing list
[email protected]
http://freenetproject.org/cgi-bin/mailman/listinfo/devl
