This product was mentioned in
with an average of
You will enjoy reading the National Institute for Science and Technology's (NIST) Special Publication 800-90b: Recommendation for the Entropy Sources Used for Random Bit Generation
They methodically develop a formula that lets you calculate how many "not perfectly random" input bits are needed, to create one cryptographically secure output bit. For Johnson noise and CMOS inverters the ratio winds up being less than or equal to 16-to-1, but you'll enjoy reading the report and cruising through the formulae yourself.
Or you could just purchase somebody else's implementation from Amazon (product link)
>The best way to pick truly random numbers is with a bunch of 10-sided dice.
Not even close. Dice have inherent idiosyncrasies that can cause some numbers to come up more often than others in the long run. That might be good enough for casual, everyday use, but you wouldn't want to base an ultra-secure cryptography system on it.
The best way to generate TRULY random numbers is by measuring some quantum event, like the radioactive decay of a nucleus, thermal noise in a semiconductor, and so on. You can buy cheap dongles that do precisely that. Because they are based on quantum events, the numbers these devices generate are not predictable even in theory.
Yes, there is.
Ironically, at least for me the fourth result on Amazon for usb random number was the Samsung 850 EVO 250GB 2.5 inch internal SSD. I, ah, hope not.
Avalanche diode noise generators are super cheap and easy to make. They make electronic noise for quantum processes. You can buy ready made ones.
TRNGs require hardware. Even in today's age of 3D printing, you cannot distribute hardware as part of a software package.
Even then, most TRNGs cannot produce randomness fast enough to keep up with demand, so instead they are fed into entropy pools used by csprngs. Generally, this is handled at the kernel level and is what crypto/rand takes advantage of.
math/rand is suitable when you need randomness without consequence, such as most video games. You need to seed it, often with the current time, so each sequence of numbers is unique. The randomness is good-enough and it saves some cycles from getting better randomness from a csprng. If someone takes the time to do the statistical analysis and determine your starting seed and can thus predict the future, no harm is done. Think of Minecraft. Each world is built from a seed value. Use a unique seed and the world feels new and random. Use a known seed and you know what the world will look like. This is the desired behavior, and is what math/rand gives you. You just need to tell Go what seed to use, or it will always generate World 1.
crypto/rand is suitable when your randomness has consequences, such as when security and/or money is on the line. It's still a prng though, because software can only produce pseudorandomness, but the csprng is seeded by the kernel using TRNGs (hopefully), and is periodically fed with entropy from the TRNGs.
You're free to buy a TRNG off Amazon, and seed math/rand from it if you really wanted, or more easily from a read to crypto/rand, but if your starting seed needs to be that unpredictable, you need to be using crypto/rand or a TRNG for all numbers, not just the seed.
You can easily use TRNGs in Go, or any other language with the ability to read from a file, but it's not needed outside of highly-specialized use cases. As a developer, you just need to determine if your randomness has consequences, pick the appropriate random package for your language, read the documentation so you understand how to use it correctly (does it need seeded, is it thread safe, etc), and let the OS handle TRNG/hardware-microcode interaction.