Re: [RFC] frandom - fast random generator module

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

Andreas Dilger  wrote:
>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.

I don't get it.  What do you mean by "increase the security"?
If your security relies on unpredictability, then with a non-cryptographic
PRNG, you have no security.  What am I missing?

I'm just not seeing how frandom is going to make your life any better
here.  In almost every security system I've ever looked at, either you
need a full-strength crypto PRNG, or else a simple counter is enough.

>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.

I am always suspicious of warm-n-fuzzy arguments, when it comes to
security.  Either it is security-critical, or it isn't.  And, if you
don't know whether or not it is security-critical, look out!

If the most compelling argument we can come up with for putting
frandom in the kernel is warm-n-fuzzies...  well, I think we can all
draw some conclusions from that.