[Cryptography] Random numbers only once

John Denker jsd at av8n.com
Wed Feb 5 16:45:05 EST 2014


On 02/05/2014 08:46 AM, Theodore Ts'o wrote:
> I have been amused for a while now how many people have been
> making assumptions without understanding how things actually work.

Physician, heal thyself.

There is such a thing as entropy -- you know, real physics entropy.
If you want to talk about something else, that's fine, but please
don't call it entropy.  Call it something else.

There are parts of linux drivers/char/random.c that make a reasonable
effort to distinguish entropy from non-entropy ... yet other parts 
utterly drop the ball.

>  because the state file could get compromised (i.e., the disk
> image gets copied/ghosted or accessed directly while the system is
> shut down), we don't make any assumptions about the state file being
> secure, and hence give no entropy credit.  

That's the wrong explanation.  Compromise has got nothing to do with it.

On linux systems, the state file in question gets written using bits 
from /dev/urandom (*not* /dev/random).  Reference:
   /etc/init.d/urandom line 76

As such, on typical systems over most of the last many years, the
state file contains zero entropy.  It would be quite ludicrous 
to reboot and load this state file and credit to the system more 
entropy afterward than before.

Let's be clear:  No entropy credit is the right answer because of 
no entropy ... for reasons having nothing to do with compromise.

=====================

On the other side of the same coin:  In a wide range of typical
systems, security depends on the state file being "secure" in
the sense of being computationally strong.  Therefore compromise
of that file is a disaster *whether or not* any entropy is
"credited" to it.

To summarize:  As applied to the state file, equating zero entropy 
to compromise is wrong coming and going:
 -- zero entropy "credit" doesn't mean you've been pwned
 -- zero entropy "credit" doesn't mean you can't be pwned

=====================

Currently typical systems make no attempt to store entropy.  This
would not be hard to do;  they just don't do it.

The usual advice is, if you store some entropy, make sure linux 
/dev/random does not get its hands on it.  That's because for 
most of the last many years, linux /dev/random has been notorious 
for wasting entropy.

  This is a moving target, and I emphatically decline to comment 
  on what "the" code doing at the moment.  I keep hoping it will
  get fixed some day.



More information about the cryptography mailing list