Kragen Sitaker wrote: >/dev/urandom *does* deplete the entropy pool; it's just that depletion >of the entropy pool doesn't keep /dev/urandom from working, but it does >keep /dev/random from working. > >My understanding is that /dev/random is only more secure than /dev/urandom >if it turns out that MD5 has undiscovered weaknesses; is that correct? Yes, exactly so. Others have quoted this as a reason not to use /dev/urandom. I think that's exactly backwards. I feel the default should be to use /dev/urandom, unless you have some unusual and very demanding application. >> 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. > >Well, a challenge that is different each time will effectively foil >replay attacks --- even a simple counter will do for that. A simple counter isn't secure against active attacks. Imagine: You use a counter for the server's challenge. Thus, the attacker can predict what the next challenge will be, call it C. The attacker can then contact the legitimate client, give it challenge C, and take the response R; then, the attacker can connect to your server, and when it receives challenge C, it can respond with response R and gain access to the server. This is somehow analogous to a man-in-the-middle attack, except it doesn't need to be done online. That said, using challenge-response authentication and then sending everything from there in the clear has its own problems, no matter how you generate challenges. It is far better to use some protocol -- e.g., SSL, SSH, IPSec -- designed to provide a secure channel. >On Linux, I just use /dev/urandom, as you recommend. On /dev/urandom-less >systems, I settled on the following. I don't know how safe it is, >and I'd be interested in comments. I dn't know. Many of the inputs you are using look pretty deterministic or predictable to me. The time and pid are quite predictable on many systems. (For instance, in some cases sendmail can be exploited to reveal pids to remote attackers [1].) The memory allocation state sounds like something that will be the same if you restart the application from the same state. And so on. On the other hand, the idea of combining many entropy sources using a cryptographic hash is a good one. If this is used for cryptographic purposes, I'd just like to see some more reliably-unpredictable sources in there, if it were me. However, maybe it's good enough for your purposes. I don't know. You might find the following URL helpful: http://www.cs.berkeley.edu/~daw/rnd/index.html I collect online resources on how to generate cryptographic-quality unpredictable pseudorandomness. [1] Ian Goldberg, David Wagner, ``Randomness and the Netscape Browser.'' Dr. Dobb's Journal, January 1996, pp. 66--70. http://www.cs.berkeley.edu/~daw/papers/ddj-netscape.html
This archive was generated by hypermail 2b30 : Mon Jul 29 2002 - 14:58:34 PDT