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. 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. (It is true that if you call /dev/urandom, other users of /dev/random may find that there is no entropy left for them. But this should only be an issue for users of /dev/random, and the latter should be rare. In any case, failing safe is far better than using rand() seeded with the time of day and failing unsafely.) >A challenge only needs to be _different_ each time. Not so. Challenges should be unpredictable. A counter would not make a very good challenge. It can't hurt, and is probably a good idea, to simply use crypto-quality random numbers in your challenge.
