But you don't need to do that. You simply take 256 bits and use them as an AES key. You then generate a stream of bits and write that to disk. Reading the disk

But you don't need to do that. You simply take 256 bits and use them as an AES key. You then generate a stream of bits and write that to disk. Reading the disk afterward is equivalent to breaking AES. Completely agreed. I've already mentioned in this post about only using the Linux CSPRNG to seed a userspace CSPRNG, because the Linux CSPRNG is horrendously slow, due to its ad-hoc design. However, if the Linux CSPRNG was AES-128 using the standard CTR_DRBG, with AES-NI, it could go north of 2 GiBps without breaking a sweat, keeping clean random.c code (it already ships aes.h), and it's backtracking resistant. However, if you're going to spend good money for hardware producing random values, at least for me, I'm going to want the best bang for my buck. If you look at https://en.wikipedia.org/wiki/Comparison_of_hardware_random_number_generators https://en.wikipedia.org/wiki/Comparison_of_hardware_random_..., you can spend $35 for the WaywardGeek "Infinite Noise RNG", which outputs 300 Kbps, or spend $24 for an RTL-SDR dongle and get about 2.8 MiBps. The value of bits per dollar is much higher with the RTL-SDR than the WaywardGeek. This is considerably cheaper than getting a radioactive sample, coupled with a Geiger counter. IDQuantique sells a product that purportedly generates millions of random bits per second. If I were gambling at a casino, I'd feel more comfortable with that than with randomness from an AES stream. Yeah, I know I'm thinking irrationally. Yeah, that is irrational. The problem with most TRNGs is that their output is biased. As a casino operator, I might be interested if the bias benefits my casino, but I would also need to prove to regulators that I'm not cheating the public. Personally, I'd err on the side of caution when it comes to the law. So either I would whiten the output with a cryptographic primitive (John von Neumann debiasing is too costly, losing at least 1/2 the bits), or just write a userspace CSPRNG, and get the throughput you'll need for the demand. I could then constantly rekey/rseed the generator with the TRNG if I was tinfoil-hat-paranoid. In either case, TRNG or CSPRNG, you'll want exceptional throughput for your casino. Which brings us back to another example of which 800 bps just isn't going to cut it. :)