in the past, i've done many different things to create entropy -
encode videos, watch youtube, tcpdump -vvv > /dev/null, compiled a
kernel. but, what is best? just whatever gets your cpu to peak or are
some tasks better than others?
Personally, I've used and recommend this USB stick: http://www.entropykey.co.uk/
Internally, it uses diodes that are reverse-biased just ever so close
to the breakdown voltage such that they randomly flip state back and
forth.
Cheers,
jof
in the past, i've done many different things to create entropy -
encode videos, watch youtube, tcpdump -vvv > /dev/null, compiled a
kernel. but, what is best? just whatever gets your cpu to peak or are
You are referring to the entropy pool used for /dev/random and
crypto operations ?
You could setup a video capture card or radio tuner card, tune it into
a good noise source, and arrange for the bit stream to get written
to /dev/random
Because anything written to /dev/random gets mixed in / XOR'ed
into the entropy pool
Yes, but then you're also introducing a way for an external attacker
to transmit data that can be mixed into your entropy pool.
While certainly a cool hack, I don't think anything like this would be
safe for cryptographic use.
</two cents>
Cheers,
jof
I find that giving a screwdriver and a hammer to a child between the ages
of 4 and 10 will usually do pretty well.
Owen
XORring predictable data to random data does not yield a predictable
result. /dev/random is world writable so if writing to it causes the
random generator to output something predictable it's a bug that needs
to be fixed. Also, an analog TV receiver will always have some noise that is
not predictable even if you are transmitting a known signal to it.
If you seriously need good entropy for cryptography, I think you will not
ask about it on nanog, and I'd be very wary of cheap hardware RNGs too.
which i guess means my tcpdump is also a bad idea...
i've heard of looking at radio, voltage, and video. i was really
wondering about a good every day solution - something easily
implemented on any computer. so maybe a way of getting random network
traffic or something random from computers around you. i'm not
verisign or any other type of company that needs to generate thousands
of keys in a day, but sometimes i need to generate a half dozen or so,
and my entropy runs out pretty quickly.
the radio idea might work for me if i could get a wire and a cheap
amplifier and plug it into a headphone jack or possibly figure out a
ccd type thing on a motor that would give me noise for my sound card.
but i was hoping for something even more simple than that - maybe wifi
noise?
Intel claims to include a hardware Digital Random Number Generator (DRNG) in its later generation chips. Is their offering inadequate/discredited?
http://en.wikipedia.org/wiki/RdRand
http://www.pcmag.com/article2/0,2817,2391367,00.asp
http://www.intel.com/p/en_US/embedded/innovation/security/walker-article-security
http://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide/
that's good to know about. i'll have to remember it when tech moves
along in a year or so. but, right now, i don't think i have that
capability. also, i'd prefer to have a chip agnostic solution as a
month or so ago, i wanted to create a key on a raspberry pi (should've
just copied one over) and it took forever to generate enough entropy -
even as i was compiling stuff. after that, i considered tcpdump.
Which is about time. It's not like this hasn't been needed for 10+ years.
Mark
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 
Finally, a good use for political talk radio.
+1.
not sure how much others care about server entropy in general.
however, after reading this:
http://strugglers.net/~andy/blog/2010/06/06/adventures-in-entropy-part-1/
i'm basically sold on that entropykey. $30 for a entropy through
electron tunneling with tons of failsafes.... wow. i might just have
to get two so i can nail the other to a frame, hang it on a wall and
geek out every now and again
I know that a popular method for generating random bit streams is to take radio (stellar) noise and convert it into a digital bit stream. Very popular among crypto geeks.
Steven Naslund
Hi Shawn,
in the past, i've done many different things to create entropy -
encode videos, watch youtube, tcpdump -vvv > /dev/null, compiled a
kernel. but, what is best? just whatever gets your cpu to peak or
are some tasks better than others?
Not necessary the best way, but haveged* might be interesting to try
out. It generates entropy based on differences in the cpu timestamp
counters. Linux-only though.
gr, Lex
*) http://www.issihosts.com/haveged/
- --
LRO-RIPE | 398E38C3 | 748D 6359 389B 4E5A 4A44 82F5 BEC5 07FD 398E 38C3
Hi Shawn,
and with ekeyd-egd-linux you can distribute the entropy from an entropykey
over the net - great for giving vm some randomness.
again, to add some input to my own question - i happened to be
compiling openssh and found this in the install doc:
NB. If you operating system supports /dev/random, you should configure
OpenSSL to use it. OpenSSH relies on OpenSSL's direct support of
/dev/random, or failing that, either prngd or egd
PRNGD:
If your system lacks kernel-based random collection, the use of Lutz
Jaenicke's PRNGd is recommended.
EGD:
The Entropy Gathering Daemon (EGD) is supported if you have a system which
lacks /dev/random and don't want to use OpenSSH's internal entropy collection.
http://www.lothar.com/tech/crypto/
hopefully i'll find the time to figure out what is different about
"OpenSSH's internal entropy collection", the above systems, and
haveged.