[lkml]   [2003]   [Oct]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] frandom - fast random generator module
    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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:58    [W:0.021 / U:1.416 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site