Just a fair warning:

The original code supplied with the paper some six years ago ('guess3d.c' and 'calprob') is crufty,
simplistic, suboptimal, and in certain scenarios downright buggy. I am no longer sure what
circumstances prompted me to produce such an abysmal and rushed piece of software. As far as I can 
tell, this had no major impact on the presented data, but it very well might affect your results 
should you decide to rely on it. Some of these problems were known to me at the time I wrote the 
paper, some were reported by others, most notably by Amit Klein in 2007 (to whom I owe big time 
for bearing with me here).

What the aforementioned problems mean is this:

  1) When an excessive search radius is specified, close to the random spacing between attractor
     elements in a data that otherwise does not respond well to phase space analysis; or the input
     set is very dense because of a limited bit width; a bug in calprob may cause false positives 
     if the script is run by a legacy version of bash. 

  2) In the cases presented in this paper, a more sophisticated and better coded implementation 
     could be more successful than guess3d.c in carrying out an simulated attack. In other words, 
     with more attention to the code, the attack likelihood figures presented in the text could be 
     slightly better. That said, these are the breaks: the data generally reflects the real-world 
     efficiency of this particular tool, and that's what a paper with "empirical" in title is
     really obliged to deliver.

For the curious - the most important problems:

  1) There is a chance of false positives in 'calprob' if you're using bash older than 2.05b
     (as it was the case for us in 2001). If you specify an excessive search radius (prompting 
     guess3d to pick up random distant attractor points) that do not produce a true behavior
     pattern match, or even a small radius on a particularly dense input set, the absolute value 
     of a difference between the actual and guessed value is then cast to a 32-bit signed int, 
     then tested for upper limit only.

     If the difference between these values is larger than 2^31-1, this will be wrapped to a
     negative integer, prompting the comparison for a successful candidate to always pass. 

     This is not a problem if you do not use a legacy version of bash, or if you specify your
     search radius conservatively. This is a really silly bug, and truly below even my sloppy
     standard of coding :/ Again, reported by Amit Klein.

  2) The implementation of radius-based candidate lookup does not use a true radial area, but a
     simplified inscribed square region instead. This assigns a disproportional weight to candidate
     values along X and Y axes at the expense of other cases, even though there is absolutely no 
     reason to expect them to be any more useful. As a result, candidates with a larger deviation
     may be chosen instead of a better counterpart in the vicinity, degrading the quality of
     produced guesses. This might or might not have an impact on your test cases.

  3) The need to specify a search radius in advance is in principle unnecessary and introduces
     a significant error if not done properly (and *some* error in all cases)  - the user is 
     forced to guess, and making a suboptimal choice might severely impair the quality of produced
     guess set by diluting it with low-quality candidates. Knowing the optimal value in advance 
     is, on the other hand, impossible. This simplified the code significantly, but is a major
     drawback.

  4) There is a subtle signedness bug in guess3d.c that causes it to reject valid candidates
     at negative Y/Z offsets. According to my tests (and gut feeling), this will not introduce a 
     very significant attack quality degradation for typical PRNGs, as over a large set of test 
     cases, there would be a large body of equally suitable attractor data points at positive
     deltas; nevertheless, this is a problem, and a yet another factor that contributes to
     a less-than-optimal performance of guess3d (reported by Amit Klein).

  5) Specifying an excessive search radius might have disastrous effects, including integer 
     overflows in the distance summing code and elswhere; there are numerous other silent 
     assumptions about the operator using sane parameters (the input is silently truncated to
     32 bits, etc), but there is no documentation for the code and no clear usage notes
     in the paper. The bottom line is, the tool was never meant to be used as a versatile
     standalone analyzer.

That said:

  1) As far as I can tell, the paper stands in principle valid, and the presented data is not
     significantly off the mark (by luck),

  2) If you're using a crufty and ancient code that uses SVGAlib, system calls to sort and bc,
     and you're not the author, you're insane. (Even the author wouldn't.)