views:

161

answers:

4

It'd be nice to be able, for some purposes, to bypass any sort of algorithmically generated random numbers in favor of natural input---say, dice rolls. Cryptographic key generation, for instance, strikes me as a situation where little enough random data is needed, and the requirement that the data be truly random is high enough, that this might be a feasible and desirable thing to do.

So what I'd like to know, before I go and get my hands dirty, is this: does any software exist for building an entropy pool directly from random digit input? Note that it's not quite enough to simply convert things from radix r to radix 2; since, for instance, 3 and 2 are relatively prime, it's not entirely straightforward to turn a radix-3 (or radix-6) number into binary digits while holding onto maximal entropy in the original input.

+4  A: 

The device /dev/random does exactly this on Linux -- maybe it would be worth looking at the source?

EDIT:

As joeytwiddle says, if sufficient randomness is unavailable, /dev/random will block, waiting for entropy to "build up" by monitoring external devices (e.g. mouse, disk drives). This may or may not be what you want. If you'd prefer never to wait and are satisfied with possibly-lower-quality randomness, use /dev/urandom instead -- it's a non-blocking pseudorandom number generator that injects randomness from /dev/random whenever it is available, making it more random than a plain deterministic PRNG. (See man /dev/urandom for further details.)

j_random_hacker
/dev/random gets some of its input from user interaction (mouse/keyboard) and from disk-access speed, both naturally affect phenomena. Without these inputs, /dev/random outputs slowly (waiting for real random data)!
joeytwiddle
/dev/random gets some of its input from user interaction (mouse/keyboard) and from disk-access speed, both naturally affected phenomena. Without these inputs, /dev/random outputs slowly (waiting for real random data)!
joeytwiddle
@joey: But IIRC root can contribute entropy to the pool and provide its own estimate. So a suitable setuid program could accept dice rolls from a trusted user, and feed them into /dev/random, which would then output as quickly as the user can roll dice (i.e. still very slowly...)
Steve Jessop
@joey, onebyone: I've edited the answer to mention /dev/urandom, which avoids blocking while still using genuine externally-captured randomness when it's available.
j_random_hacker
+2  A: 

This paper suggests various approaches with implementation ideas for both UN*X and Windows.

anon
+2  A: 

I'm not sure what you're asking for. "Entropy pool" is just a word for "some random numbers", so you could certainly use dice rolls; simply use them as the seen to a pseudorandom number generator that has the characteristics you want.

You can get physically generated random numbers online from, eg, Lavarnd or Hotbits.

Charlie Martin
I assume that by "entropy pool" he means what I'd call an entropy collector. So not just "some random numbers", but a device which accepts inputs together with an entropy estimate for each input, and gives outputs provided that there is enough entropy in its current state for the number of bits requested.
Steve Jessop
A: 

Note that the amount of entropy in the pool doesn't necessarily have to be an integer. This should mostly deal with your prime-factors-other-than-2 issue.

Even if you end up using an implementation that does require integer estimates, you need quite a few dice rolls to generate a crypto key. So you could just demand them in bunches. If the user gives you the results of 10 d6 rolls, and you estimate the entropy as 25 bits, you've only lost 0.08 bits per dice roll. Remember to round down ;-)

Btw, I would treat asking the user for TRNG data, rather than drawing it from hardware sources as /dev/random does, to be a fun toy rather than an improvement. It's difficult enough for experts to generate random numbers - you don't want to leave general users at the mercy of their own amateurism. "The generation of random numbers is too important to be left to chance" --Robert Coveyou.

By another way, the authors of BSD argue that since entropy estimation for practical sources on PC hardware isn't all that well understood (being a physics problem, not a math problem), using a PRNG isn't actually that bad an option, provided that it is well-reseeded according to Schneier / Kelsey / Ferguson's Yarrow design. Your dice idea does at least have the advantage over typical sources of entropy for /dev/random, that as long as the user can be trusted to find fair dice and roll them properly, you can confidently put a lower bound the entropy. It has the disadvantage that an observer with a good pair of binoculars and/or a means of eavesdropping on their keyboard (e.g. by its E/M emissions) can break the whole scheme, so really it all depends on your threat model.

Steve Jessop
Algorithmically, it's a solved problem---see <http://en.wikipedia.org/wiki/Sampling_equiprobably_with_dice>. I'm talking rather about actual software that provides an interface for gathering the input.
Steven Dee
So you're after a full package including UI? Personally I'd settle for wrapping my own UI, with my own estimates, around a commodity entropy collector.
Steve Jessop
"Algorithmically, it's a solved problem" - use 8-sided dice, available from any RPG store ;-)
Steve Jessop