best way to create entropy?
mysidia at gmail.com
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
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
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 :)
More information about the NANOG