best way to create entropy?

Fri Oct 12 03:12:08 UTC 2012

On 10/11/12, Jonathan Lassoff <jof at thejof.com> wrote:
> Yes, but then you're also introducing a way for an external attacker
> to transmit data that can be mixed into your entropy pool.

The binary operations used to  'mix in'  data  preserve entropy, when
non-random data is mixed in,     given the birwise operation     A
(+)  B.
The result is guaranteed to have  entropy no less than the entropy of
A,   and also guaranteed to have entropy no less than the entropy of
B.

The transmitter/source  of data does not control the system's
administrative structures, so it is not possible for one source of
data to "reduce"  or "compromise" the entropy of an entropy pool.

An external attacker would have to have a way of making the other
sources of entropy unavailable,  and  make sure the system
over-estimates the amount of remaining entropy, to ensure _no_  new
entropy is available, other than their fake entropy.      That risk is
dwarfed by the risk of physical tampering, installation of remote bugs
to steal key material, etc.

> While certainly a cool hack, I don't think anything like this would be
> safe for cryptographic use.

These methods of generating entropy, when implemented reasonably, are
far better than perfectly adequate  for the generation of random
numbers for one time pads,  and cryptographic  keys for  long term
use;    for very high security purposes, as in  3-letter agency use,
multiple independent sources of entropy are recommended.

For high security applications,  actions should always be contemplated
to detect or protect against tampering  with the hardware and
software,   or using software to steal key material.

That may involve the use of  smart cards,  or dedicated
single-purpose  hardware security modules  to generate and store keys,
  so a general purpose computer never has access  to the keys,   only
a very simple one,  that performs just the required crypto operations,
 when the  proper number of authorized users   prove their identity
and ask  the device to perform crypto operations.

For applications that don't require that...  RF noise from one source
fed to  /dev/random  is  highly adequate :)

> jof
--
-JH