The fastest random-number generator ever built
nature.com
nature.com
Now that we have packaged chiplets, we should be open to stuff on a different semiconductor process than our CPU cores.
Where we need random bits as fast as they can be had is when running Monte Carlo processes on GPUs. There, the sources need to be on-chip because interconnect would be too expensive; we need a separate bit source integrated into each functional unit, and producing a whole machine word's worth each cycle, so a word is always ready immediately when it could be used. Sometime we need more than one before starting a computation.
In terms of using randomness is crypto, you actually don’t need that much. If you have 256 bits, or 512 bits for an crazy amount of safety factor, you should be good to go. A lot of the secure PRNG’s are built in the same principles as our encryption algorithms. If we don’t trust those, we likely have much bigger issues with the foundations of cryptography.
Although, I wonder if an invention like this allows for some new developments in crypto protocols that are extremely "random hungry" in the same way that modern innovation in NNs was made possible by scaled up processors (GPUs / accelerated NN chips).
ie just XOR your plaintext with a random "key" the length of your plaintext
This is essentially what a modern cipher does, except that the key is a keystream and is generated deterministically from the actual key. This is objectively better than just using a really big key -- it means your shared secret only needs to be e.g. 32 bytes, rather than len(plaintext) bytes!
I do still think there's an important use case for high-volume "good" entropy, though: it should replace essentially all uses of "bad" entropy (generated by weak pseudo-random generators, maybe seeded with a few dozen bits of entropy). Programmers should have to go out of their way to get weak entropy, rather than the other way around. Historically programmers have reached for weak RNGs because they tend to be much faster and more convenient to use than the strong RNGs. We should flip that equation. We don't necessarily need a device like this one to do that, but it might help.
Yes. One application is Monte-Carlo methods. When the function is fast to compute, especially when running on GPUs with thousands of concurrent threads, good RNG is hard.
Still, it would be nice to remove the CSPRNG from the equation entirely, and just read from the stream of "pure"/"true" randomness directly. On the other hand, there are obvious downsides to getting your entropy from a single source... I guess it comes down to a simple question: which do you trust more, your hardware or your software?
I was similarly confused about which property of the photons they were measuring, it seemed they might be measuring the number of photons over specific periods of time. Because the position of each individual photon is uncertain until it is destructively measured, randomness will be generated by the "collapse" of the wave function, where one of the possible outputs is generated. Before measuring, photons can be in a "superposition" of bouncing inside the bow tie shaped chamber, or escaping out of the laser to be measured. After measuring, a photon can either be inside the laser, or outside the laser, but not the "both" of a previous superposition. Arguably, superposition isn't really a "both", but there aren't great words in English for this unfortunately. The fundamental uncertainty of measuring a superposed quantum state has been convincingly demonstrated in experimentation, but nobody really knows _why_ it happens this way. The "measurement problem" has inspired many interpretations of quantum mechanics, but many of them are unfalsifiable.
As noted in other comments, if you seed a reasonable cryptographic scheme with enough entropy up-front (and protect it well), you shouldn't constantly need to produce more.
So, what practical application would this have?
- Most crypto schemes haven't been proven secure in any absolute sense, only relative to other problems we think are hard.
- Protecting that entropy can be hard.
- Crypto is expensive. If you need a high bit-rate (another comment mentioned GPU Monte Carlo) then integrating these on-chip could be cheaper than mangling the same entropy source over and over.
- Adding to the above, using the same entropy source in multiple places can be prone to non-obvious bugs and race conditions where you use identical or correlated random bits.
Also, less secure applications often cannot get by with dropping the cryptographic constraint, and it might not be obvious when it can be safely dropped (even ignoring the arguments that usually crop up in these kinds of discussions like how for an online poker match you probably do need secure RNG) -- e.g., non-crypto RNG is prone to linear dependences and other problems which can significantly and qualitatively change the nature of all but the most trivial simulations.