[Cryptography] Random numbers only once
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