[831] in bugtraq
Re: preventing sequence number guessing
daemon@ATHENA.MIT.EDU (der Mouse)
Sat Jan 28 10:36:25 1995
Date: Sat, 28 Jan 1995 09:48:13 -0500
From: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
To: dawagner@phoenix.Princeton.EDU
Cc: bugtraq@fc.net
>>> 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 sounds awefully expensive. One md5 operation for each new
>> passive or active connection.
> On an unloaded Sparc LX, I get
> ~/scratch/md5 $ time ./md5drivr -t
> MD5 time trial. Digesting 1000000 8-byte blocks ... done
> Digest = 2278bf63bfa354c582138cde1233fd15
> Time = 7 seconds
> Speed = 1142857 bytes/second
> 6.776s real 6.680s user 0.090s system 99% ./md5drivr -t
> So it takes about 7 u-seconds to MD5 hash a small block on a fairly
> wimpy Sun. [It's faster on faster boxes, of course.]
Perhaps not. MD5 has relatively high overhead; that is, in the
time = overhead + (perbyte * bytes)
formula, "overhead" is comparatively large[%]. If, as the message
implies, your md5drivr program is digesting a million 8-byte blocks
into a single MD5 hash, then the overhead is being amortized over 8
million bytes. This would not be the case in the proposed use of it to
generate ISN values.
This is not to say that MD5 is too expensive. It may be fine. I'm
just pointing out that your results do not necessarily imply what they
seem to at first glance.
[%] This is largely because of the rounding up required by the way MD5
hashes the input in units of 512 bits, and the appending of the
length of the bit string. The formula I gave is over-simplistic;
MD5's actual cost is more like
time = constant * round_up(bytes+9,64)
der Mouse
mouse@collatz.mcrcim.mcgill.edu
