I did mention that already: https://news.ycombinator.com/item?id=18955720 "If the device ever powers down, you will need 32 bytes worth of persistent storage, so you don't repeat the random stream every time you boot up."

> You haven't addressed the bit where you're presenting a solution in search of a problem.

Here's the problem: if the attacker controls one or several of the random sources, they may partially control the output of the RNG. In some cases, a simple bias can lead to catastrophic key recovery attacks (ECDSA comes to mind). In other cases, the attacker could simply use the RNG as a communication channel. It only takes 4 tries to control 2 bits of a hash. This is also described in the link you should really really follow.

> I'm quite familiar with random devices (i.e., Fortuna) and stream ciphers, thank you.

Good. Then you know that a stream cipher such as Chacha20 is a suitable high security RNG for long term keys (otherwise it wouldn't be suitable even as a stream cipher). The only problem is forward secrecy (the key used by the stream cipher is necessarily stored somewhere, and if it gets stolen, all past keys, including ephemerals!, are toast). That's what fast key erasure is for: have a 512 byte buffer or so, whose first 32 bytes are filled with your current seed. Stream 512 bytes from that seed and overwrite the entire buffer with it. The first 32 bytes will seed the next batch of random bytes. The rest can be distributed to the API user. (Also don't let users access the RNG state, they're obviously going to duplicate it.)

---

By the way, DJB points out that our go-to persistent storage, hard drives and SSD, aren't exactly easy to erase. Which is quite crucial for the forward secrecy fast key erasure achieves. My opinion is that every computer should come up with a dedicated persistent writeable (and over-writeable) memory. The tiniest chip should be able to afford 32 bytes of such memory.