Subject: Re: NFS and reserved ports
To: Jonathan Stone <jonathan@DSG.Stanford.EDU>
From: Jim Reid <firstname.lastname@example.org>
Date: 03/24/1997 16:51:19
>>>>> "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
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