> > Andreas Beck wrote: > >> On systems with /dev/urandom, the following function will give challenge > >> strings which should be immune to the problems discussed: > > > >DONT do this. This will deplete the random pool for no good reason. > > I believe your comment is incorrect or misleading. I believe /dev/urandom > will not deplete the randomness pool, and I suspect using /dev/urandom > is a good idea. Try it. Actually it appears that /dev/urandom does deplete the randomness pool in Linux at least (and you sortof concede this later in your post I think.) I will quote a comment from /usr/src/linux-2.4.19rc1/drivers/char/random.c * The two other interfaces are two character devices /dev/random and * /dev/urandom. /dev/random is suitable for use when very high * quality randomness is desired (for example, for key generation or * one-time pads), as it will only return a maximum of the number of * bits of randomness (as estimated by the random number generator) * contained in the entropy pool. * * The /dev/urandom device does not have this limit, and will return * as many bytes as are requested. As more and more random bytes are * requested without giving time for the entropy pool to recharge, * this will result in random numbers that are merely cryptographically * strong. For many applications, however, this is acceptable. The important bit I think being in the 2nd paragraph "without giving time for the entropy pool to recharge" which appears to say urandom initially pulls from the entropy pool until it runs out. (I'll admit I nearly fired off an email similar to yours, but then I scanned the source and...) > Don't confuse /dev/random with /dev/urandom. /dev/random depletes > the randomness pool, but should rarely be used in applications, IMHO. > /dev/urandom is typically the right choice, and continues to give output > without blocking to wait for more entropy input. Well this issue does come up sometimes, particularly for, say, headless webservers with only network and disk activity and drivers for said that one or the other don't do add_foo_randomness(). For those people saying "don't worry about losing real entropy" is not looked favorably upon when they need real entropy for ssh servers or ipsec or whatever... (I seem to recall a couple of months ago a push on linux-kernel to increase the places that called add_randomness() for precisely this reason.) Note also I'm not debating here whether VNC or any particular app should be using the random/urandom interfaces, only trying to help clear up whether that depletes the entropy pool. Also everyone should note VNC is GPL'ed code and nothing is preventing anyone from adding --use-urandom or --use-egd or whatever if they like. M
This archive was generated by hypermail 2b30 : Fri Jul 26 2002 - 08:23:28 PDT