[Ach] Recomendation on haveged in Bettercrypto chapter 3.3.3

[Aaron Zauner]

Hi,

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.
```


Aaron

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cert.at/pipermail/ach/attachments/20150429/244cae26/attachment.sig>