Re: $RANDOM not Cryptographically secure pseudorandom number generator

[Chet Ramey]

On 12/15/18 5:22 PM, Ole Tange wrote:

>>> The reason for my submission was that I needed a bunch of random
>>> numbers in a shell script, but I needed them to be high quality.
>>> Luckily I did not just assume that Bash delivers high quality random
>>> numbers, but I read the source code, and then found that the quality
>>> was low. I do not think must users would do that.
>>
>> This is always requirements-driven. Nobody expects to get cryptographic-
>> quality PRNGs out of the shell (or any of the libc interfaces, tbh),
> 
> While I did not *expect* it, I honestly had hoped for it. Otherwise I
> would never have raised this.

OK. What would you expect out of a PRNG that limits the range to 0-32767?


> I feel a bit as if I am saying: "Hey this using environment variables
> to store function definitions seems like it could be a problem, but I
> do not have an exploit. I do, however, have an easy fix so that it
> will not be a problem in the future."
> 
> And you replying: "Come back when you have an exploit."
> 
> And then we simply wait for Shellshock to happen.

If at some future point you look back and want to know when your argument
went off the rails: this is it.


>> that's never been promised or expected. You can't really expect that from
>> something that only promises 16 bits.
> 
> The naive user may assume that he can simply concatenate values and
> get 128 bits:
> 
> echo $RANDOM-$RANDOM-$RANDOM-$RANDOM-$RANDOM-$RANDOM-$RANDOM-$RANDOM
> 
> But I hope we agree that he will not get 128 bits of randomness no
> matter how many values he concatenates.

He'll get better than 16 bits.

> Or he might expect that this is not an infinite loop:
> 
>   while [ ! $RANDOM = $RANDOM ] ; do true; done

What does this have to do with the strength of a PRNG? Very few generators
will give you the same random number twice in succession.

> just like this is not:
> 
>   while [ ! $RANDOM = $(( 1+$RANDOM )) ] ; do true; done
> 
> (This one came as a surprise to me - I had totally expected $RANDOM
> would give the same value twice 1 time in 65536 tries on average.

It's very difficult to get a random number generator with a perfect period.
But even if you did, the above is a nonsensical test -- there's no reason
to think that you'd avoid two random numbers whose difference is 1 during
the sequence.

> At the very least make it clear from the documentation what $RANDOM
> can be used for. The man page does not warn about the low quality
> either, and it does not point to a way to get high quality numbers.

The bash PRNG is pretty good when generating 32 bits. It's the same
algorithm that FreeBSD and Mac OS X use for rand(). It's cutting down
to the lowest 16 bits that reduces the period.

> Somehow we expect the user to simply know this without giving him even
> a hint about this.
> 
>> However, for common scripting tasks like generating temporary filenames,
>> it's perfectly adequate.
> 
> I hope that we agree that you should never use $RANDOM for generating
> temporary file names in a dir that an attacker has write access to.

This is a different problem. There is a whole set of other issues involved
with creating temporary filenames in the presence of other processes.

The real issue is that, since the algorithm is public, the seed becomes
very important. If you have suggestions about how to improve the seeding,
please send them along.


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/