On Fri, 04 Mar 2005, Marco Colombo wrote: > You do want to use /dev/random for your session keys. _They_ are > likely going to attack your session keys, not your master key. The whole > point is to guess as many bits as possible of the kernel PRNG state.
Which, in a Cyrus server, won't be helpful since there is a lot of disk activity and the PRNG state changes quite often, provided you don't keep it drained (and thus without activity because nobody can talk to the server!). Using random instead of urandom goes a long way into helping to keep the pool drained (the kernels usually protect a small amount of entropy won't let urandom drain it completely). > /dev/random blocks when the kernel thinks the PRNG state could have > already been guessed, in pure theory. So the attacker would be able guess The hard facts are that most kernel entropy accounting is not anywhere close to exact enough, so we cannot rely on it on anything close to a border condition (such as the entropy pool being empty, which is the only time urandom differs too much from random). You *are* already depending on the security of the PRNG for small ammounts of time (when the entropy in the pool is "close" to zero). Given that fact, IMHO you are much better using urandom anyway, because the system will still work enough close to an empty entropy pool to regen that pool a bit. > anyway - but you have to trust it). Once the attacker knows the output of > your /dev/urandom, he knows all the session keys your host will generate. If, and only if, you have no new entropy going in. If you have a few bits of entropy going in, they have a reduced search space (which IS already a very bad thing)... unless the kernel does a catastrophic reseed of the PRNG. Which on newer Linux kernels for example, it does as often as it possibly can. > It happened in the past, some software used to generate 128 bit keys was > buggy and the actual number of possible combinations was much much smaller > (say 2^20). But the same PRNG and the same hash function are used by > /dev/random as well, so it isn't much safer in this respect. It won't be any safer, you mean. Well, I am not afraid of the SHA search space, in Linux, BSDs and Solaris, that have somewhat good PRNGs. The state of the entropy pool changes unpredictably quite often enough. > If your kernel runs out of random bits, you should find a reliable source > of randomness and feed it into the kernel. I do. In fact, I have a 25kbit/s entropy feed into the kernel pool in such a way that I force a catastrophic reseed at least every second, and I am also working with the merkensleep.com guys to get rng-tools to a point where you can easily send entropy over the network from something like a VIA Nehemiah step 8 (a couple Mbit/s of entropy, sweet...) to a cluster. > to try 2^4096 possible combinations, not 2^8192. Usually the kernel pool > is large enough (and can be enlarged at run time in modern Linux kernels). At least so far. Someone was talking about removing "that useless feature", so keep an eye for it to make sure they don't. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
