Subject: Re: NFS and reserved ports
To: Frank van der Linden <email@example.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 03/24/1997 06:38:27
>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
Uh, but ... how are you going to get high-bandwidth randomness to do
anything useful and `strongly random' with an entire partition worth
of inodes -- 9 Gigabytes or more, for some installations?
Conversely, if the high-quality randomness is really only used for the
first inode, can't an attacker simply wait until they snoop a mount
request, and use that (and subsequent readdir() operations) and
the source of fsirand to guess the generation number of any inode?
(Think of this as a problem where each inode/ generation-number pair
you capture gives you another plaintext/cyphertext pair.)
So then: how do you smear the relatively few high-quality bits you've
got (presumably at boot time, or at best when single-user) across the
inodes of a really large filesystem?
Historically, didn't the original SunOS implementation get by without
high-quality randomness? How good was that? Anyone know of good
studies in breaking SunOS 4.x filehandles?
Last, since the current fsirand is so FFS-specific, and has to be run
on clean filesystems, the FS-specific fsck back-end (fsck_ffs) might
be a better place to put the functionality -- or even newfs.