Re: [RFC] frandom - fast random generator module

[daw@mozart.cs.berkeley.edu (David Wagner)]

Andreas Dilger  wrote:
>Hmm, so every part of the kernel that doesn't need crypto-secure RNG data
>(i.e. fast and relatively unique) should implement its own hash/PRNG then?
>It isn't a matter of unbreakable crypto, but the fact that we want relatively
>unique values that will not be the same on a reboot.  Currently we do just
>as you propose for our "crappy PRNG", which is "grab 8 bytes via
>get_random_bytes and increment", but that is a little _too_ easy to guess
>(although good enough for the time being).

I guess I don't understand this objection.

I'm having a hard time understanding the requirements for your PRNG.
In one place you say you just want uniqueness, but then in another
place you talk about it being easy to guess.  If all we care about is
uniqueness, why should ease of guessing matter?  I'm confused.

If all we need is uniqueness, then I don't see what's wrong with grabbing
8 bytes from get_random_bytes() and incrementing.  In particular, you
don't need frandom in this case.

If we need both uniqueness and unpredictability, then grab 8 bytes
from get_random_bytes() each time you need a new value.  This will
satisfy both your requirements.  If you truly do need something hard
to guess, nothing less than a full-strength crypto PRNG will suffice.
In particular, frandom won't help you in this case.

What am I missing?