Jim Reid <jim@mpn.cp.philips.com> writes:

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

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

<Boggle> If the filehandles are ephemeral, how do you propose to
handle server crashes?  If they're not ephemeral, where do you keep
them?


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

So, we have a better PRNG, and we can set the intialization vector
from a high-quality random number source (/dev/random), at least when
/dev/random exists.  That's what I was assuming as a baseline.
How good is that, given that the inodes and and their generation
numbers get exposed?