|
Re: Cryptographic Random Numbers
by halley (Prior) on Jul 07, 2003 at 18:56 UTC
|
There are several strata of pseudo-random number generators (PRNG). For 99% of the requirements performed in Perl, the built-in rand() works just fine. It is even smart enough to use an internally defined seeding strategy if no seeding was already performed, usually out-doing anyone's naive code that tries to mix $$ ^ time().
What you are recommending is a high-cost solution to fulfill the last 1% of PRNG users. Crypto-hard PRNG, as you say, needs to incorporate feedback from other available entropy sources. These perturb the normal chains so that even knowing the past history of generated numbers won't help in predicting the next number.
However, I have to point out two weaknesses here.
- Not much entropy
You only propose one source of entropy available to the Perl interpreter. There may be more, but it's pretty clear that the interpreter is not in a great position to sample from a wide variety of sources. It may watch artifacts of high-resolution time, artifacts of memory allocation, artifacts of the current codebase, and maybe artifacts of data throughput. Generally, a Perl application is only heavily affecting one of these sources at a time, in predictable patterns that are internal to one single process, so the overall entropic input is an unuseful trickle.
- Not hardened against access
The Perl interpreter is a user-land process, and as such, has no security against anything else within its own process space. If an attacker wanted to affect or tap your process's CPRNG, eval "use Untrusted_XS_Module;" and it's done. On some operating systems, other processes could even crack your process without tainted data attacks. CPRNGs must be kept within hardened black boxes, and as such, the operating system's kernel is really the only place that comes close on today's mortal computers.
I won't even discuss runtime costs, because perhaps there are some magic ways of gaining entropy for free.
I agree with your sentiment: a standard for accessing CPRNG resources is desirable, but not appropriate within the Perl interpreter.
--
[ e d @ h a l l e y . c c ] | [reply]
[d/l]
[select] |
Re: Cryptographic Random Numbers
by adrianh (Chancellor) on Jul 07, 2003 at 18:46 UTC
|
I'm not a security expert, but I would have thought that the time of the next perl instruction would be too susceptible to user manipulation to be a good entropy source.
An alternative to finding a local source is to use something like Math::RandomOrg and get the source externally.
| [reply] |
|
|
Gah! I'm not a security expert, but I know enough that should I require some cryptographically strong random numbers, the last place I want to fetch them would be from some disinterested third party (even if I do have a couple of links on my homenode).
For really, really strong numbers, I would read from the blocking version of the kernel's entropy pool, /dev/random on BSD, /dev/urandom (I believe) on Linux, and EGD on Solaris (at least on the ancient 2.6 I'm using). For merely really strong numbers but high volume, I'd just use output from one of those to seed a good PRNG, such as the Mersenne Twister (for which a Perl module exists... hmm, no, two competing modules, Rand::MersenneTwister and Math::Random::MT). This PRNG has a 2**19937-1 period, and can be fed to a digest function to produce stronger bits, at a certain cost in speed.
The main point is that you can, and should, always generate them locally.
_____________________________________________
Come to YAPC::Europe 2003 in Paris, 23-25 July 2003.
| [reply] |
|
|
| [reply] |
|
|
What you believe is right ;-)
Any programmer can just read a few megs from /dev/urandom, write it to a file (dd is a handy utility to achieve quick results) and try to gzip or bzip it. If the file can be compressed with a high ratio it is a shame for the urandom coders, if not then it is a shame for gzip or bzip coders (and refreshing for crypto-minded programmers ;-)
(ok, ok, just a joke :)
To put it shortly: You already have the random numbers in kernel (I mean Linux).
| [reply]
[d/l]
[select] |
|
|
|
|
|
|
| [reply] |
Re: Cryptographic Random Numbers
by Anonymous Monk on Jul 07, 2003 at 18:51 UTC
|
I have to disagree. The utility of extra code to use perl's timings as entropy is too limited to warrant including it in the core modules, much less the interpreter itself. How often do most programmers need *good* random numbers? It might make an interesting module, if you could get it to work. Sounds like XS hell to me. | [reply] |
•Re: Cryptographic Random Numbers
by merlyn (Sage) on Jul 07, 2003 at 23:12 UTC
|
Standard module that works on every platform
Have you found a platform on which Math::TrulyRandom does not work? If so, have you contacted the author?
Are you merely asking that something like that be made "core"? I don't agree. I don't think that every user needs it, enough to pad an already bloated core. And if it's need, it's trivial to install.
-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.
| [reply] |
|
|
| [reply] |
|
|
OK, let me back off a little. The mechanism of Yarrow or whatever its successor is called would certainly go into a module, complete with lots of dependancies. The only think I'm proposing the CORE for is one cheap entropy source.
—John
| [reply] |
Re: Cryptographic Random Numbers
by chunlou (Curate) on Jul 07, 2003 at 21:40 UTC
|
Somehow reminded me of Perl 6, which I don't know much about. But should someone want to build a more cryptography-oriented Perl "kernel" (just as you have different flavors of Linux), would Perl 6 and Parrot make it more possible and even easier? Or am I off the mark?
Another general question. Say, if you generate random numbers with the help of a Geiger counter (~100 USD, hooked up to RS-232), how would the kernel approach help here?
| [reply] |
|
|
| [reply] |
Re: Cryptographic Random Numbers
by wufnik (Friar) on Jul 08, 2003 at 13:36 UTC
|
for what it is worth, i agree with part of John M. Dlugosz's suggestion: not necessarily via the perl kernel, but
certainly via a standard module which can be used to collect entropy in a platform independent manner.
it is surprisingly difficult to find libraries that do this. i tried yarrow, which has a good entropy collector,
and good documentation, from which i intended to parrot unmercifully, but the entropy collecting source given is windows-specific. and /dev/random is great if you have a linux box, but obviously not otherwise.
re: math::trulyrandom, the readme itself says, in a rather plaintive & guilty tone, something like "statistical tests should be performed on the output, but the slowness of the module is problematic". i find it hard to believe that statistical tests are absent, given how easy it is to actually perform the tests with something like ent. and besides, it works just for unixen.
i find myself again bemoaning the fact that it is quite hard to find truly cross platform cryptographic code in perl. so yes, give us a cross-platform entropy source.
please! just don't put it in the kernel.
ttfn,
wufnik
...in the world of the mules there are no rules | [reply] |
Re: Cryptographic Random Numbers
by hardburn (Abbot) on Jul 08, 2003 at 14:07 UTC
|
Some of the newer chipsets from Intel and AMD have built-in hardware RNGs. IIRC, AMD's newest chips are getting them built into the CPU itself.
If you don't have one of those, it's quite easy to build one yourself. You need a resistor and some way to precisely measure its resistance and send the values into a serial or parrellel port. The method of choosing a resistor get's stood on its head from normal practices--older resistors with high tolerance values are better (more entropy), provided it still conducts electricity.
In the program that reads the data from the RNG, you want to throw away the first couple of decimal places (maybe down the the ten-thousandth place, maybe more, depending on your level of paranoia). Gather a few thousand bits (again, adjust for your level of paranoia, as more bits == higher entropy) and run it through an SHA1 sum. You now have 160 bits of high-quality random numbers.
You should be able to accomplish this in a user-space driver. On *nix systems, it would be preferable to put it right in the kernel in order to feed the bits into /dev/random.
----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer
Note: All code is untested, unless otherwise stated
| [reply] |
|
|
| [reply] |