[Cryptography] Random numbers only once

Darren Moffat darren at nessieroo.com
Thu Feb 6 04:15:15 EST 2014

On 05/02/2014 21:45, John Denker wrote:
> 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.

Which is exactly what we do in Solaris (and what Illumos etc do as 
well).  Any writes to /dev/random or /dev/urandom or their equivalents 
that come over /dev/crypto with the appropriate ioctl (for emulation of 
PKCS#11 semantics) are allowed to be mixed into the pool (assuming the 
callers cred has sufficient privilege) but are considered to contribute 
exact 0 entropy credit to the pool state.

Solaris unlike Linux also doesn't expose any stats about the internal 
state of the whole rng subsystem to userspace.  The only way to find 
that out is being root with all privilege and using the kernel 
debugger.   Are we being too paranoid or should we expose to user space 
the current stats about what we believe the amount of entropy etc is ?

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

We don't do it on Solaris, however as part of our just completed FIPS 
140-2 validation NIST asked is if we could do that. The reason they 
asked was they wanted to be sure that there was sufficient entropy 
available for when the first parts of the system start calling on a FIPS 
186 PRNG to do key generation.

While I've written up an example system service that does this have no 
plans of integrating it into Solaris as default part of the product.

Given how rarely many server systems reboot and that fact that most 
critical key generation is more likely to be done on the first one or 
two boots afer intial install I think this is pointless anyway.

Darren J Moffat

This email is free from viruses and malware because avast! Antivirus protection is active.

More information about the cryptography mailing list