On 08/08/2017 03:33 PM, Tom Buskey wrote:
> On Tue, Aug 8, 2017 at 3:18 PM, Joshua Judson Rosen <roz...@hackerposse.com
> <mailto:roz...@hackerposse.com>> wrote:
>
> On 08/08/2017 02:52 PM, Ken D'Ambrosio wrote:
> > On 2017-08-08 14:43, Bill Freeman wrote:
> >> As to why ruby is designed to require a random number before being
> >> asked to do something dependent on such a random number is a question
> >> for the ruby developers.
>
> I assume you meant not dependent.
He probably did actually mean "dependent", but also meant "before"
as in "well in advance of" and not "at the moment when"--
i.e. "why ruby is designed to require a random number before anyone
has asked it to do anything dependent on such a random number",
i.e. "why ruby is designed to require a random number despite not yet
having been asked to do anything that actually needs it".
I can't really offer any insight into the Ruby devs, but I can offer
a story that illustrates why someone might choose `eager PRNG initialization'
(what Ruby is doing) over `lazy PRNG initialization' (what Python and Perl do).
Once upon a time, I inherited a playlist-generator written in Perl;
the way it operated, it wold fork off subprocesses and do things
with random numbers in the subprocesses to select the next song in the playlist.
Basically something like this:
while (1) {
if (fork == 0) {
print rand . "\n";
exit;
} else {
wait;
}
sleep 1;
}
This all worked perfectly fine until I added a call, somewhere in the program
before it got into that loop, to some subroutine that itself needed to
generate a random number for some reason. I don't specifically recall what that
subroutine was..., but the point here is actually that it may not
have even been evident to me as the caller that somewhere down
in the bowels of the new subroutine the PRNG was going to get called.
But it completely broke my playlist-generator, basically like this:
print "One random number: " . rand . "\n";
while (1) {
if (fork == 0) {
print rand . "\n";
exit;
} else {
wait;
}
sleep 1;
}
Perl uses lazy initialization of its PRNG: if you don't explicitly initialize
it,
it auto-initializes at the point of first invocation.
And if the first invocation is after a fork, the child process
receives a copy of the uninitialized PRNG and initializes it itself
without affecting the still-uninitialized PRNG in the parent process.
And this situation can repeat just the same for each child process.
But if the first invocation is _before_ a fork, then the child process
receives a copy of the _initialized_ PRNG state, generates `the next number'
without affecting the pre-initialized PRNG state in the parent process.
And this situation can repeat just the same for each child process--
with each child process inheriting _the same pre-initialized PRNG state_.
So, the lazily-initialized PRNG basically provided a trap for
the programs's authors/maintainers to fall into: everything `worked just fine'
until a subtle/hidden change occurred to the program's overall
entropy-consumption patterns. It was... interesting....,
figuring out how the playlist-generator started to just repeat
the same song over and over again.
Eager initialization of course wouldn't have prevented the
`cloned PRNG state' problem, but it would have made it immediately
visible up front instead of laying a trap that snared me years later.
(also: there are ways of triggering a re-init on fork as well,
and it looks like Ruby even does that--with an accompanying
comment of "We don't want reproduce CVE-2003-0900.").
As Bill said, "predictability is a bad thing" when it comes to
the specific outputs of a random number generator;
but predictability of whether/when your generator is going to
DTRT or fail entirely is quite a nice thing :)
--
Connect with me on the GNU social network:
<https://status.hackerposse.com/rozzin>
Not on the network? Ask me for an invitation to the nhcrossing.com social hub!
_______________________________________________
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
