Why calculate pi to estimate randomness? Why do testing suites calculate $\pi$ (pi) using the Monte Carlo method to determine if a series of numbers are random?  As far as I can tell, the Monte Carlo method can be used to estimate $\pi$ itself (as a numeric means of calculating it).  It just so happens to use random numbers.

Why does it have to be $\pi$ if you're testing a numeric sequence for randomness?  It seems that plotting random points inside and outside a circle to get $3.1415 \dots$ achieves exactly the same as plotting points inside /outside a triangle to get $0.5$.  Is there something special about the circular shape pertinent to cryptography?
Knowledgeable crypto practitioners do not calculate $\pi$ using a Monte Carlo method to determine if a series of numbers are random.

The test alluded to in the question is a general-purpose¹ randomness test for random number generators with output a real number expected to be uniform of the range $[0\dots1[$. The test consists of drawing pairs $(x,y)$, and determining the proportion such that $x^2+y^2&lt;1$, which should be about $\pi/4$ (because that's the area of the intersection of a square of side $1$ with a disc of radius $1$ and center in a corner of the square, and any subset of the square is expected to get a proportion of the random draws proportional to its area).

Variants of this test can be made for random number generators with bit or integer output, as used in cryptography. However this test is not particularly good, or often used.



Further, general purpose RNG tests are generally not very useful in cryptography:


If applied to the output of a PRNG, such test will declare the RNG good including for cryptographically very weak and poorly seeded PRNG (such as a LFSR seeded with all 1).
If applied to the output of a TRNG directly based on a physical phenomena (such as thermal noise filtered by removing the DC component, keeping polarity, and sampling at a relatively low frequency), many such general purpose tests will tend to fail due to minor bias in the conditioning circuitry, even though the TRNG is working as designed and perfectly usable after conditioning by a properly designed CSPRNG.


In my opinion, the only technically² justifiable use of a general-purpose¹ randomness test in a cryptographic context is to detect gross malfunction³. The archetypal tests for that are the Monobit, Poker and Runs test formerly in FIPS&nbsp;140-1 and FIPS&nbsp;140-2; these tests are sound in principle, but had been specified to ridiculously stringent acceptance levels, making these tests usable only on the output of a PRNG, thus largely pointless (per 1. above). After a hiccup altering the acceptance levels, reason prevailed and these tests are no longer mandatory at startup of a FIPS 140-2 device.

A sorry side effect of the above historical error is that the habit of running Monobit and Poker test sticks, hence designers of hardware TRNG strive to have their generators pass these tests to the most stringent levels, hence have an incentive to avoid exposing their inner entropy source before a fair amount of poorly documented conditioning. That makes it more challenging than needed to devise a good field test of the TRNG; that is, a test that reliably catches dangerous defects appearing in a deployed device (including purposely induced defects, e.g. when a Smart Card is cooled by evaporation of a liquefied gas in hope to literally freeze the TRNG), and do so without causing false alarms and/or permanently disabling perfectly good devices.



¹ By general-purpose I mean intended as detecting any deviation from true random, with acceptance level set accordingly. This includes NIST SP 800-22 rev 1a.

² Getting rubber-stamped is a justifiable goal in itself.

³ Detecting gross malfunction is a justifiable goal at some design stage. Validating the design of a cryptographic gizmo (or worse, algorithm) primarily on the basis of the absence of detection of gross malfunction is poor methodology.