>>>>> "Jonathan" == Jonathan Stone <jonathan@DSG.Stanford.EDU> writes:

    >> It was looked at, and as you can see, fsirand(8) is already in
    >> the tree.  I believe the completion of this is currently
    >> stalled on a good /dev/random implementation.

    Jonathan> Uh, but ... how are you going to get high-bandwidth
    Jonathan> randomness to do anything useful and `strongly random'
    Jonathan> with an entire partition worth of inodes -- 9 Gigabytes
    Jonathan> or more, for some installations?

With a bit of work obviously. :-)

    Jonathan> So then: how do you smear the relatively few
    Jonathan> high-quality bits you've got (presumably at boot time,
    Jonathan> or at best when single-user) across the inodes of a
    Jonathan> really large filesystem?

I was thinking of something like creating filehandles on the fly and
then crypting them with a key derived by something supplied by the
client at mount time. [Lots of handwaving here.] The server could
cache these for a while to save on per-request crypts.

    Jonathan> Historically, didn't the original SunOS implementation
    Jonathan> get by without high-quality randomness?  How good was
    Jonathan> that?  Anyone know of good studies in breaking SunOS 4.x
    Jonathan> filehandles?

It got by. It wasn't much good. See the nfsbug program. It's up for
ftp at CERT I think. It was able to guess SunOS 4 file handles and
anything else which used the same/similar fsirand code. The basic
problem was a poor random number generator tied to an easily guessed
initialisation vector.