entropy depletion

[William Allen Simpson]

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 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.
>
If we could actually get such devices, that would be good. 

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 majordomo at metzdowd.com