Ian G wrote:
(4A) Programs must be audited to ensure that they do not use /dev/random improperly.
(4B) Accesses to /dev/random should be logged.
I'm confused by this aggresive containment of the entropy/random device. I'm assuming here that /dev/random is the entropy device (better renamed as /dev/entropy) and Urandom is the real good PRNG which doesn't block post-good-state.
Yes, that's my assumption (and practice for many years).
If we could actually get such devices, that would be good.If I take out 1000 bits from the *entropy* device, what difference does it make to the state? It has no state, other than a collection of unused entropy bits, which aren't really state, because there is no relationship from one bit to any other bit. By definition. They get depleted, and more gets collected, which by definition are unrelated.
In the real world, /dev/random is an emulated entropy device. It hopes
to pick up bits and pieces of entropy and mashes them together. In
common implementations, it fakes a guess of the current level of
entropy accumulated, and blocks when depleted.
If there really were no relation to the previous output -- that is, a _perfect_ lack of information about the underlying mechanism, such as the argument that Hawking radiation conveys no information out of black holes -- then it would never need to block, and there would never have been a need for /dev/urandom!
(Much smarter people than I have been arguing about the information
theoretic principles of entropy in areas of physics and mathematics
for a very long time.)
All I know is that it's really hard to get non-externally-observable sources of entropy in embedded systems such as routers, my long-time area of endeavor. I'm happy to add in externally observable sources such as communications checksums and timing, as long as they can be mixed in unpredictable ways with the internal sources, to produce the emulated entropy device.
Because it blocks, it is a critical resource, and should be logged.
After all, a malicious user might be grabbing all the entropy as a denial of service attack.
Also, a malicious user might be monitoring the resource, looking for cases where the output isn't actually very random. In my experience, rather a lot of supposed sources of entropy aren't very good.
Why then restrict it to non-communications usages?
Because we are starting from the postulate that observation of the output could (however remotely) give away information about the underlying state of the entropy generator(s).
What does it matter if an SSH daemon leaks bits used in its *own* key generation if those bits can never be used for any other purpose?
I was thinking about cookies and magic numbers, generally transmitted verbatum. However, since we have a ready source of non-blocking keying material in /dev/urandom, it seems to be better to use that instead of the blocking critical resource....
-- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]