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 ]