Graphing Randomness in TCP Initial Sequence Numbers

Saint Aardvark writes "This is neat: Graphic visualization of how random TCP Initial Sequence Numbers really are for different OSs. It's a great way of seeing how secure a TCP stack really is. Cisco IOS is great; OS9, OpenVMS and IRIX aren't. Posted to the ever-lovin' BugTraq mailing list." This is a follow-up to the previous report.

Already Slashdotted

[Quixote]

The story's barely out on /. and its already slashdotted.

/. story submission page should have a checkbox: "Please mirror the contents of this page (including graphics, which Google doesn't cache) before posting the story".

3rd parties don't have the authority

[DrSkwid]

"Please could you violate the site's copyright before posting the story"

although "please use server xxx.xxx as the proxy" for submissions could be a solution

could even set up Apache to do that on a url therefore subtly circumventing the copyright problem, banners could be passed through.

Understanding Randomness

[Nosher]

Lets face it: current computers and humans are both as bad as each other at randomness. The fact that computers have to "calculate" randomness is a bad sign in itself, and the humans that program these computers are almost utterly incapable of perceiving true randomness anyway. I'm waiting for the day when the national lottery comes up 1,2,3,4,5 with a bonus ball of 6. Society will crumble, public enquiries will be called for and conspiracy theorists will have something to bang on about for years. I think that barring the sudden development of Quantum x86 chips (at which point randomness becomes "real" and encryption becomes pretty much unbreakable [theregister.co.uk]), the only real solution for decent randomness must surely be TCP/IP seeding based on Lava Lamps [sciencenews.org]

Lessons in RNG

[Anonymous Coward]

Posting anonymously because I'm not a whore.

Given that the server is slashdotted, here are a few facts about pseudo-random number generators:

Linear Congruential Generators are infamous for certain weaknesses, most notably that n-tuples fall "mainly on the planes": they lie on hyperplanes in higher dimensional space, depending on the additive and multiplicative parameters chosen.

This doesn't mean that they are any worse for cryptography purposes, because even if you choose parameters that aren't as bad, once the generator parameters are determined and a seed is found, the sequence is deterministic.

But, all is not lost. Modern generators often use shuffling techniques, where you keep track of a few dozen numbers at a time, and then pick one number to determine which of the pool to select, and a second number to replace that selected number. Even a poor LCG when accompanied by such a shuffling technique can perform well. Well, not a really poor one--IIRC randu had problems that shuffling would not fix. I believe the gnu lrand48 and friends use this shuffling technique, as well as CMUCL. I suppose this can be even better if you populate the initial pool of numbers from outside the pseudo-random sequence, so that the potential attacker has almost no shot at figuring out what you seeds are, but to scientists who aren't worried about cryptographic purposes, that is counter-productive. I believe that there are some generators that have been proven 'non-invertible'--you can not go backwards in the sequence except by performing brute force search. Whether or not TCP geeks use these is beyond my knowledge.

But, all is still not safe. You have to be careful about how you change your random number into a usable number. Often people use the high-order bits (e.g., they multiply by some number and then round off). This can be a mistake (of course depending on what your generator really is, and what your purposes are).

Re:Understanding Randomness

[Nosher]

Absolutely. I'm sure there are other, numerous, ways of utilising the properties of "hardware" to generate something far more random than a programming algorithm could ever achieve. And this is the paradox - why, when it is so straightforward (and cheap) to get true randomness from the unstable, analogue properties of simple electronic devices, do they not feature more commonly as a basic mobo component (whither the random number generator DIMM module?), in the way that, for example, there's *always* a system clock (or at least timer) available. Instead, more effort has been invested in trying to emulate randomness with increasingly complex software-based algorithms that can never be really random precisely because they are programs.