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? 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20101109/c0540e81/attachment.pgp>
