And I remember that fsirand wasn't (or isn't?) really that random
either. One of the very first NFS hacks I saw was Leendert van Doorns
nfsbug thing that guessed SunOS file handles, exploiting a weakness
in their fsirand implementation. You can't produce good random numbers
fast, which is what fsirand would have to.
Actually, MD5 is probably fast enough so that disk speeds would be the
blocking factor for fsirand, not the crypto algorithm. Simply generate
a secret, and then calculate the MD5 hash of the secret plus the inode
number, and chop off what you need from the resulting hash for the
generation number.
The big caveat here is that generation numbers don't really help you
that much as far as secuurity goes. Sure, it protects against file
handle guessing attacks, but that's only one of a number of ways which
justify the old saw about NFS == "No File Security".
NFS does have some real cryptographically based security options now,
but those will either have to be implemented and distributed outside the
United States (i.e., outside the "crypto iron curtain") or we're going
to have to wait until the end of the year to see if the U.S. Government
has really come to its senses about this issue. (We won't know for sure
until the fine print in the federal regulations are released, which is
scheduled to happen in December.)
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/