[Ach] Recomendation on haveged in Bettercrypto chapter 3.3.3
azet at azet.org
Wed Apr 29 19:38:10 CEST 2015
Manuel Kraus wrote:
> Ever watched "/proc/sys/kernel/random/entropy_avail" over some time?
> The fluctuation of that value on a busy system speaks for itself.
> At least to me, well, wearing just a sysadmin hat too. ;-)
I'm not sure what your system does but if it's not producing thousands
of one-time-pads per second you're well off with the entropy that you see.
People seem to think that entropy magically makes their crypto more
secure. This is not the case in the way crypto primitives use randomness
sources on modern operating systems. Please see `man 4 random` for more
details (don't believe the manpage w.r.t. using random for /some/
things, though - use urandom).
Let me quote these paragraphs:
The kernel random-number generator is designed to produce
a small amount of high-quality seed material to seed a
cryptographic pseudo-random number generator (CPRNG). It
is designed for security, not speed, and is poorly suited
to generating large amounts of random data. Users should
be very economical in the amount of seed material that
they read from /dev/urandom (and /dev/random); unnecessar-
ily reading large quantities of data from this device will
have a negative impact on other users of the device.
The amount of seed material required to generate a crypto-
graphic key equals the effective key size of the key. For
example, a 3072-bit RSA or Diffie-Hellman private key has
an effective key size of 128 bits (it requires about 2^128
operations to break) so a key generator only needs 128
bits (16 bytes) of seed material from /dev/random.
While some safety margin above that minimum is reasonable,
as a guard against flaws in the CPRNG algorithm, no cryp-
tographic primitive available today can hope to promise
more than 256 bits of security, so if any program reads
more than 256 bits (32 bytes) from the kernel random pool
per invocation, or per reasonable reseed interval (not
less than one minute), that should be taken as a sign that
its cryptography is not skilfully implemented.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: OpenPGP digital signature
More information about the Ach