On Tue, Oct 05, 2004 at 11:27:05 +0200, Marco Colombo <[EMAIL PROTECTED]> wrote: > On Mon, 4 Oct 2004, Bruno Wolff III wrote: > > >You don't want to use /dev/random. You aren't going to get better random > >numbers that way and blocking reads is a big problem. > > Sure you are. As far as the entropy pool isn't empty, /dev/random > won't block, and thus there's no difference in behaviour.
/dev/random blocking is a huge problem. > When you're short of random bits, /dev/random blocks, /dev/urandom > falls back to a PRNG + hash (I think SHA1). Under these conditions, > /dev/urandom output has 0 "entropy" at all: an attacker can predict > the output after short observation provided that he can break SHA1. We aren't worried about an attacker breaking SHA1 in this case because we are just generating a seed for srandom which isn't cryptographically secure. What you have to worry about is using so many values that the nonrandomness is appearant. This will generally become appearant after roughly 2^(number of bits in state / 2) samples. That isn't going to happen when the /dev/urandom is being used to generate a seed. > That is, anything that uses /dev/urandom (when the kernel pool is > empty) is just as safe as SHA1 is. SHA1 is pretty safe for this purpose. The recent weaknesses of related hashes isn't going to be of much help in predicting the output of /dev/urandom. If SHA1 were to be broken that badly /dev/random would also be broken. The reason to add in entropy is protect against your state having been leaked once and having an attacker be able to always be able to know what the next output is going to be without having further access to the state. I don't believe the way linux mixes in entropy protects against this attack. If you mix in too little entropy between output values you can figure what entropy was added by going through all possible entropy values and seeing which one gives the expected output. (This assumes that you have gotten a copy of the internal state at some point.) My memory of looking at the /dev/[u]random code is that there is just one entropy pool and entropy is added to it as it is obtained. So that if values are obtained from /dev/[u]random at a high enough rate the above attack is practical. So the only case where you might want to use /dev/random over /dev/urandom is where the internal state is vunerable, the attacker has access to a large fraction of the output values and where there are at least some gaps between samples where large amounts of entropy are collected. ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
