Re: [RFC] frandom - fast random generator module

[Andreas Dilger]

On Oct 16, 2003  19:17 -0400, Jeff Garzik wrote:
> Andreas Dilger wrote:
> > 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).
> 
> If you care at all about it being easy to guess, then why bother with 
> the crappy PRNG?  :)
> 
> If you _don't_ care about the numbers being easy to guess -- i.e. you 
> simply want unique values -- then it doesn't seem like a PRNG is needed 
> at all.  With a random number you have to deal with collisions between 
> nodes choosing the same number coincidentally _anyway_, so why not just 
> use sequence numbers?

For the current version of Lustre security is not a primary concern (our
customers run Lustre in very secure network environments).  We started
with get_random_bytes() but had to remove it because of the overhead.
Note that the random numbers are produced and consumed local to a single
node but are passed over the network to clients as an opaque handle,
so cross-node collisions are not a concern.

At some point in the future we may need to increase the security of such
handles, but it would be nice to not increase the CPU usage as much as
get_random_bytes() did.  Direct HW RNG would suit this perfectly.

Note that the security of these handles isn't really that critical to
the overall security model when implemented (which will be kerberos based
like AFS and DCE), but it would be nice from a warm-n-fuzzy point of view
to have something better than "last handle + N" which is what we have now.

In any case, this is getting off topic for l-k now so we should probably
end the discussion here.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/