summaryrefslogtreecommitdiff
path: root/pod/perlfunc.pod
diff options
context:
space:
mode:
authorAbhijit Menon-Sen <ams@toroid.org>2011-12-01 05:32:35 +0530
committerAbhijit Menon-Sen <ams@toroid.org>2011-12-01 05:32:35 +0530
commit416e3a83ca713283356a2dba4bbf8fa3e01402ad (patch)
tree595d772f6d91c65da55724948f5dc4138364bc0a /pod/perlfunc.pod
parenta6642c724ba3d83b31349dfd9e0e569fa13e96e9 (diff)
downloadperl-416e3a83ca713283356a2dba4bbf8fa3e01402ad.tar.gz
Don't suggest using srand for "cryptographic purposes"
Also, don't suggest Math::Random::MT::Perl as a source of cryptographically secure randomness, because it isn't.
Diffstat (limited to 'pod/perlfunc.pod')
-rw-r--r--pod/perlfunc.pod26
1 files changed, 10 insertions, 16 deletions
diff --git a/pod/perlfunc.pod b/pod/perlfunc.pod
index 532ea3b94d..604123daf8 100644
--- a/pod/perlfunc.pod
+++ b/pod/perlfunc.pod
@@ -4876,8 +4876,8 @@ B<C<rand()> is not cryptographically secure. You should not rely
on it in security-sensitive situations.> As of this writing, a
number of third-party CPAN modules offer random number generators
intended by their authors to be cryptographically secure,
-including: L<Math::Random::Secure>, L<Math::Random::MT::Perl>, and
-L<Math::TrulyRandom>.
+including: L<Data::Entropy>, L<Crypt::Random>, L<Math::Random::Secure>,
+and L<Math::TrulyRandom>.
=item read FILEHANDLE,SCALAR,LENGTH,OFFSET
X<read> X<file, read>
@@ -6627,10 +6627,7 @@ C<srand()> at all.
But there are a few situations in recent Perls where programs are likely to
want to call C<srand>. One is for generating predictable results generally for
testing or debugging. There, you use C<srand($seed)>, with the same C<$seed>
-each time. Another other case is where you need a cryptographically-strong
-starting point rather than the generally acceptable default, which is based on
-time of day, process ID, and memory allocation, or the F</dev/urandom> device
-if available. And still another case is that you may want to call C<srand()>
+each time. Another case is that you may want to call C<srand()>
after a C<fork()> to avoid child processes sharing the same seed value as the
parent (and consequently each other).
@@ -6649,16 +6646,6 @@ current C<time>. This isn't a particularly good seed, so many old
programs supply their own seed value (often C<time ^ $$> or C<time ^
($$ + ($$ << 15))>), but that isn't necessary any more.
-For cryptographic purposes, however, you need something much more random
-than the default seed. Checksumming the compressed output of one or more
-rapidly changing operating system status programs is the usual method. For
-example:
-
- srand (time ^ $$ ^ unpack "%L*", `ps axww | gzip -f`);
-
-If you're particularly concerned with this, search the CPAN for
-random number generator modules instead of rolling out your own.
-
Frequently called programs (like CGI scripts) that simply use
time ^ $$
@@ -6674,6 +6661,13 @@ combinations to test comprehensively in the time available to it each run. It
can test a random subset each time, and should there be a failure, log the seed
used for that run so that it can later be used to reproduce the same results.
+B<C<rand()> is not cryptographically secure. You should not rely
+on it in security-sensitive situations.> As of this writing, a
+number of third-party CPAN modules offer random number generators
+intended by their authors to be cryptographically secure,
+including: L<Data::Entropy>, L<Crypt::Random>, L<Math::Random::Secure>,
+and L<Math::TrulyRandom>.
+
=item stat FILEHANDLE
X<stat> X<file, status> X<ctime>