With the Raspberry Pi having a good hardware random number generator and virtual machines and containers potentially having so little, especially shortly after boot, it makes it a cheap source. Amazon’s SQS provides a fully managed, reliable message delivery system and it’s cheap, free at low volume. This seems like an excellent way to deliver Entropy to all your virtual infrastructure. Sending Entropy to the Queue Once you’ve created an SQS queue this python code will periodically (sleepfor) fetch the queue length if it’s below (lowwatermark) it will add (burstadd) messages to the queue, each message will contain 512 bytes of base64 encoded entropy.

The Raspberry Pi has long come with a hardware random number generator, it’s right here: /dev/hwrng but the OS isn’t using it by default. You can test the quality of it’s output with the ent utility dd if=/dev/hwrng bs=1k count=1 |ent example output: 1+0 records in 1+0 records out 1024 bytes (1.0 kB, 1.0 KiB) copied, 0.00956855 s, 107 kB/s Entropy = 7.833804 bits per byte. Optimum compression would reduce the size of this 1024 byte file by 2 percent.

There’s been a lot of talk about Entropy as a Service lately and as someone with an interest in security it got me thinking why, what devices are really lacking entropy such that they’d risk pulling in someone else’s… IoT devices needing to generate Strong cryptographic keys on or shortly after boot, Gitlab runners (Docker containers where /dev/random is not passed from the parent). Sounds like there is a need.