[botan-devel] Tmp dir used as an entropy source
Rickard.Bellgrim at certezza.net
Wed Sep 4 18:05:23 EDT 2013
> All that said, I am not particularly tied to ls /tmp as a source so if for whatever
> reason this particular one is of great concern to your users it can be removed
> without issue, but I hope I've made it clear how that is a very small part of a
> larger issue surrounding entropy collection. Also, if earlier polls (eg
> /dev/random or EGD) succeed, then we will never query these sources at all,
> as spawning off all these processes is quite slow, so we avoid it except in
> cases where it is necessary due to lack of other options.
Thank you Jack, for an excellent answer. We will see where this discussion will end on the OpenDNSSEC mailing list.
One of our users noticed that the Unix commands were executed even if the /dev/random had a good pool of entropy. So I looked into the code of the Device_EntropySource and may have seen some issues with the code.
Can't it be cases where you try to read e.g. 32 bytes from /dev/random, but only get back e.g. 20 bytes? The Device_EntropySource::poll() will only check that we got data back, but not how much. It will then break out from the for-loop and never try the other devices like /dev/urandom. Shouldn't the code check if the entropy goal has been fulfilled before breaking out of the for-loop?
There is also an integer rounding issue when calculating the go_get variable in Device_EntropySource::poll(). Shouldn't the integer division be rounded up to get a correct calculation? So that we can reach the entropy goal. 128 / 7 = 18,2857...
Then there is just a cosmetic thing, the read_wait_ms variable will always be equal to 100. This is because the go_get variable will never be larger than 32.
More information about the botan-devel