I don't know what to say. I could write you an entire dissertation on the math, my previous formal education in cryptography and randomness, my reading of that

I don't know what to say. I could write you an entire dissertation on the math, my previous formal education in cryptography and randomness, my reading of that code inside the golang standard library, and so forth. But you seem to be stating that you're literally unsatisfiable by any series of words from any other humans on the planet at any level of transitivity at all, even one hop. So it begs the question of why engage in communication at all, when the endgame you're interested in seems be defeat in detail. > Did you verify that this one is not stubbed out at this time, on your platform, in your particular jurisdiction? No? I did, in fact. I've performed full diverse double compilation on the golang compiler and standard library using different toolchains and different versions of the toolchains and verified the binary results. I am indeed quite confident that this random method is not stubbed out in any place on earth you or I are likely to find it. Reconsider your presumptuous dismissal. The layer below this in the golang standard library is documented as follows: // On Linux, Reader uses getrandom(2) if available, /dev/urandom otherwise. // On OpenBSD, Reader uses getentropy(2). // On other Unix-like systems, Reader reads from /dev/urandom. // On Windows systems, Reader uses the CryptGenRandom API. If you find those APIs to be insufficient on those operating systems... go you. You have some security papers to publish. I also believe the universe is made of four dimensions, one of which is time and moves almost entirely forwards, if you'd like to carry out any more attacks on things that are "faith-based" because they're insufficiently sussed out here. Might be a little out-of-scope on whether or not Teleconsole got their session IDs right, though.