[207] in linux-security and linux-alert archive
Re: randomizing filehandles: why not use fsirand?
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Fri Apr 14 00:09:33 1995
Date: Thu, 13 Apr 1995 22:08:14 +0500
From: "Theodore Ts'o" <tytso@MIT.EDU>
To: "Peter Bouthoorn" <bouthoorn@uni4nn.iaf.nl>
Cc: linux-security@tarsier.cv.nrao.edu
In-Reply-To: Peter Bouthoorn's message of Sat, 8 Apr 1995 14:00:03 +0100 (METDST),
<199504081300.AA06588@uni4nn.iaf.nl>
Date: Sat, 8 Apr 1995 14:00:03 +0100 (METDST)
From: "Peter Bouthoorn" <bouthoorn@uni4nn.iaf.nl>
I've wondered why noone (to my knowledge) has suggested to write
a tool similar to fsirand. Fsirand randomizes all inode numbers
on a system, which makes guessing file handles a little harder.
Of course the randomization used in such a tool should be
"really random", so that we don't end up with the same problem
as SunOS: the random element used in fsirand wasn't random enough.
Comments anyone?
(putting on my security hat)
I have a set of kernel patches which implement a "really random"
/dev/random. It works by sampling environmental noise from keyboard
timings and other peripherals, and mixing it together using a
cryptographic hash function. It's been something that I've been working
for the past couple of months, on and off, but I finally finished it
only last week.
It's currently waiting for a couple of other security experts to go over
my code and my algorithms, to make sure I didn't miss anything that
might compromise "really random"-ness of the code. (The idea is that
the end result should be good enough even for the purposes of generating
keying material for public or secret key systems.) After it's been
audited by a couple of people whom I trust, I'll make it available for
general distribution.
- Ted
