preventing sequence number guessing

[dawagner () phoenix Princeton EDU (David A. Wagner)]

I'm certainly no security expert, but I had a fairly simple idea
for fixing the sequence number guessing vulnerability.  Hopefully
someone can tell me whether it's worthless or not.  Hunting season's
open -- shoot it down at will. :-)

When OS boots up, grab lots of entropy and use MD5 to hash it
into a 32 bit seed; initialize tcp_iss with it.  Now let the
kernel do its normal "increment tcp_iss a little for every new
connection and every couple of clock ticks" schtick as always.
I've only got one novel idea: instead of using tcp_iss directly
for the SYN everytime a new TCP/IP connection is opened, send
MD5(tcp_iss) [or maybe MD5(tcp_iss, time(NULL), ...)].

This implements a cryptographically strong random number generator
for the sequence numbers; then attackers would have to invert
MD5 to predict sequence numbers.  MD5 is quite fast (is it fast
enough?) and is completely exportable.  Code for MD5 is available
for anonymous ftp on ripem.msu.edu /pub/crypt/other/md5.zip.

To nitpick, tcp_iss should be a full 64 bit (or even larger :-)
data type; this is easy enough to change in the kernel: (right?)

unsigned long tcp_iss_a[2];

void increment_iss(void)
{
        if (++tcp_iss_a[1] == 0)
                tcp_iss_a[0]++;
}

[When tcp_iss is only a 32 bit int, the attacker could conceivably
predict the next sequence number with 2^32 MD5 calculations by
brute force inversion of MD5 -- while this threat is not worrisome
if tcp_iss cycles around in less than the time it takes for the
attacker to exhaustively invert MD5, 64 bits is really a better
solution, and doesn't cost ya anything.]

To nitpick, tcp_iss should be never be incremented by an even number.
[If it's incremented by 128, you effectively reduce tcp_iss from a
n bit data type to a n-7 bit data type, etc.]

To nitpick, grabbing enough entropy at bootup time isn't completely
trivial; but you can do it with a little effort by hashing in access
times on /dev/null, /dev/zero, /bin/ls, /bin/tcsh, ... and by hashing
things like the current time [though note: this is accessible to
everyone who can run uptime(1)].

This is similar to the suggestion Steve Bellovin suggested in his
ipext.ps paper, except MD5 is faster than DES, and exportable to
boot, and I added some obvious (to me -- which means they may be
questionable:-) details.

So, am I missing some important kernel feature which shoots this
all down?  Or is this actually a worthwhile technique?  [If it
is worthwhile, it seems like it'd be pretty easy to code -- but
I have no experience at kernel programming, so I haven't done it
myself. <sigh>]

-------------------------------------------------------------------------------
David Wagner                                             dawagner () princeton edu