From owner-freebsd-current Thu May 23 09:41:22 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA27892 for current-outgoing; Thu, 23 May 1996 09:41:22 -0700 (PDT) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA27885 for ; Thu, 23 May 1996 09:41:17 -0700 (PDT) Received: from shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.5/8.7.3) with ESMTP id JAA11518; Thu, 23 May 1996 09:40:06 -0700 (PDT) Message-Id: <199605231640.JAA11518@precipice.shockwave.com> To: Warner Losh cc: Garrett Wollman , Poul-Henning Kamp , current@FreeBSD.ORG, blh@nol.net Subject: Re: freebsd + synfloods + ip spoofing In-reply-to: Your message of "Thu, 23 May 1996 10:21:07 MDT." <199605231621.KAA10068@rover.village.org> Date: Thu, 23 May 1996 09:40:06 -0700 From: Paul Traina Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Well, the MD5 hash would make it much less predictable, even it it was stable, so that could certainly be the reason. Say we do: ulong foo[] = MD5(hostname+secret+random); tcp_iss += 0x3ffff & (foo[0] ^ foo[1] ^ foo[2] ^ foo[3]); that should give us the properties we want. The bottom bits get highly jittered and should (hah) be relatively unpredictable (who knows how the xor hurts MD5). From: Warner Losh Subject: Re: freebsd + synfloods + ip spoofing : That offers no improvement over just randomization. As long as the randomization isn't predictible, yes. I'm not sure why they suggest the MD-5 hash. I wrote: : Per attempt is easy to ramdomize w/o violating 793 since you still : have 2^31 bits of randomness that you can use (since the original 31 bits Paul again: : However, the random number generator that we're using could be badly broken >>, : which is why I want to get BHL's tools and verify his tests. If it is a pseudo random number sequence generater, then it buys you nothing over += 30 because it is predictible (even if it is uniform and looks random). I've not tkaen a look at the code to know for sure if the randomness is good enough or not. Likely you need to do a /dev/random sort of thing that will be both uniform and unpredictable. Warner P.S. /dev/random here is a entropy gatherer in the kernel for the purpose of generating cryptographically strong random numbers. -stable doesn't seem to have this, not sure about -current. Linux does which is where I'm getting the nomenclature from.