Messages in this thread |  | | | From | (David Wagner) | | Subject | Re: [RFC] frandom - fast random generator module | | Date | Thu, 16 Oct 2003 21:03:31 +0000 (UTC) |
| |
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? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |