Random Numbers in Perl

[Kevin Buettner]

On Nov 8,  5:43pm, Nathan Saper wrote:

> On Wed, Nov 08, 2000 at 08:41:11AM -0700, Jason wrote:
> > Nathan Saper wrote:
> > > > The most common portable method of obtaining cryptographically strong
> > > > random numbers is to generate a seed using the HACK device. (Human At
> > > > Computer Keyboard :) I believe PGP relies on this method.
> > > This is probably a stupid question, but: What would be the best way to
> > > implement this sort of arrangement in Perl?
> > 
> > Ive given this some thought, and have decided that I would need to
> > know more about the specific nature of your application to answer.
> > Obviously, the timing of individual keystrokes is not available to a
> > perl script running on a remote webserver, which only sees a
> > form-submit as a single clump of data. Basically, with the requirement
> > for that level of interactivity, totally independant perl coding isnt
> > possible.
> 
> The app I'm trying to code is client-server, so a client program could
> do timing of keystrokes.  In fact, this would probably be the best way
> to do it.  I'm just not sure what the best way would be to implement
> this sort of thing in Perl.

Unless you're willing to spend *a lot* of time on it, you're probably
better off using a canned solution like /dev/random.  Sure, you can
collect keystroke timings for an entropy pool, but you still have to
convert the entropy pool into good random numbers.

If you read the code which implements /dev/random, you'll see that it
does use timings (I'm not sure if keyboard keypresses are considered
or not) from various of your computer's I/O subsystems in order to
generate its entropy pool.  The numbers that you get out of
/dev/random are pretty good random numbers so long as you do not ask
for them too fast.  (If you use up the entropy in the entropy pool too
quickly, it falls back on pseudo-random techniques for a while...)

If you don't wish to use /dev/random for some reason, you should at
least find a well regarded package like PGP or GPG and adapt its
randomization techniques to your code.  Be sure you read the licenses
*before* you look at the code so that you're not surprised later on.

The other thing to think about in your client/server application is
the communication of your entropy data from the client to the server. 
If you expose this data in any way (such as sending it in the clear
from the client to the server), you've compromised the randomness of
the numbers that you wish to later generate since an attacker who has
this entropy data will then be able to use this data to predict the
numbers that you're generating.  (I think it's probably a mistake to
try to collect entropy from the clients; if you do, you'll need to be
absolutely certain that this entropy is sent securely from client to
server.)

Kevin