lkml.org 
[lkml]   [2001]   [Oct]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
Subject/dev/random entropy calculations broken?
On Oct 01, 2001  11:52 +0200, Florian Weimer wrote:
> daw@mozart.cs.berkeley.edu (David Wagner) writes:
> > Incrementing the entropy counter based on externally observable
> > values is dangerous.
>
> How do you want to collect any entropy with such a requirement in
> place? Computers tend to send out a lot of information on the air.
>
> BTW, I still think that the entropy estimate for mouse movements is
> much too high. And the compression function used probably doesn't
> have the intended property.

Has anyone even checked whether the current entropy estimates even work
properly? I was testing this, and it appears something is terribly wrong.
Check /proc/sys/kernel/random/entropy_avail. On a system that has been
running any length of time, it should be 4096 (512 bytes * 8 bits of
entropy for a full pool).

Now, "dd if=/dev/random bs=16 count=1 | wc -c" and check entropy_avail
again. It "loses" thousands of bits of entropy for generating 16 bytes
(128 bits) of random data. Same thing happens with /dev/urandom consuming
the available entropy.

Now if you do the above test on /dev/random several times in a row, you see
that you really HAVE used up the entropy, because it will return a number
of bytes less than what you requested. At this point, however, it is at
least consistent, returning a number of bytes = entropy_avail/8.

Ted, any ideas about this? I'm just looking through the code to see where
the entropy is counted, and where it goes. It _may_ be a bug with the
entropy_avail value itself, but then why the short reads? The output values
are at least consistent in that they grow slowly only when kb/mouse/disk
activity happens, and are constant otherwise.

This may be a major source of problems for entropy-poor environments, since
you will basically only be able to read a single random value from /dev/random
before the pool "dries up", regardless of the pool size (I tried with a
4096-byte pool, and the same problem happens). Hence, in such systems there
would be more of a desire to use the "less secure" network interrupts for
entropy.

Cheers, Andreas

PS - For systems which have _some_ entropy, but just not very much, it is
possible to increase the size of the pool (if it actually worked ;-)
so that you can save entropy for periods of high demand. You can do
this by "echo 4096 > /proc/sys/kernel/random/poolsize" (or some other
larger power-of-two size).
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:03    [W:0.155 / U:11.004 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site