I was browsing through twitter mentions of @adrian_otto and found one posted by Ian Thompson mentioning an article about weak randomness in the cloud. It suggests that because there may be insufficient entropy sources on a Cloud Server or instance that it may make it easier to guess random number sequences because different cloud servers may have similar or even identical entropy pools (or worse yet identical host keys) when created, and therefore easier to break encryption algorithms that depend on them.

Yes, if you have similar entropy pools it is easier to break encryption dependent on it. It’s reasonably easy to work around this and make sure your entropy pool is uniquely initialized. You can consult the random manual for the Linux Kernel for information about how to seed your entropy pool with a particular set of data. If you are running an application in the cloud that utilizes encryption, and you are concerned about the initial state of your entropy pool, you can solve that. Use this procedure:

1) Seed your own pool from a long running system that has sufficient entropy in it, rather than relying on what you read from the kernel at startup.

2) Produce a network service that you use to seed your initial entropy pools. This service could be as simple as an entropy file that you create on pseudo-random time intervals, and just discard them as you serve them to cloud server instances (as they boot up) so you never serve the same one twice. At boot time from your VM, simply connect to wherever you run this service and download an input file to seed your entropy pool with. Restrict access to this so that it’s only available to your own server instances.

3) Make sure that your custom entropy pool initialization takes place prior to starting your encryption software.

4) If you are creating an AMI, or other server image that you plan to clone, be sure that it does not have a host key generated yet. Delete it and allow your initialization scripts to create it when the server is created (after step rather than making copies of the same one.

If you don’t trust what /dev/random or /dev/urandom emit, you can optionally use OpenSSL with prngd or egd as alternate entropy sources, and potentially feed in your own sensory input data. If you want to go hardcore, you could add environmental noise such as resistor noise on the microphone input of a sound card, or some other sensory data. There is existing software for doing just that. There’s all sorts of possibilities. Among them are a number of hardware solutions for RNG, most of which are pretty expensive and are not options for a cloud environment. There are sources of random numbers provided as a service from various sources.

There are things that we can do as Cloud Computing service providers to pre-initialize your entropy pools for you when the given server instance is created so the procedure above would be redundant. This still leaves the question as to the quality of the RNG available to you on a cloud server.

There are two standard randomness sources that you should know about:

/dev/random = produces actual entropy, if you have some, and blocks otherwise.
/dev/urandom = produces available entropy regardless of quality, but does not block.

The Linux kernel has a paravirtual entropy driver which provides kernel-side support for the virtual RNG hardware. The kernel compile option CONFIG_HW_RANDOM_VIRTIO enables it, and it can be built as a kernel module. There are drivers that run within the hypervisor host kernel that connect this with the RNG hardware available on the server (if any).

drivers/char/hw_random/amd-rng.ko = H/W RNG driver for AMD chipsets
drivers/char/hw_random/intel-rng.ko = H/W RNG driver for Intel chipsets
drivers/char/hw_random/virtio-rng.ko = VirtIO Random Number Generator support

How it works is the hypervisor host (dom0) runs rngd to read data from /dev/hwrandom (using the Intel or AMD modules mentoined above) and feeds it into /dev/random, then the guest VM (domU) does the same thing. The rngd can mixes data from both /dev/random and /dev/urandom so you get as much random data as you need in a non-blocking fashion. You can consult the kernel source code to learn more. Then you run rngd in the guest VM to feed that into the kernel.

What happens if multiple guest VM’s are reading this data at the same time using this arrangement? I’m not sure if it’s possible to deplete the entropy pool of the hypervisor host and produce PRNG patterns that are therefore less random. So if one guest VM emptied the entropy pool by aggressively reading from the /dev/hwrandom device, you might cause someone else’s guest VM to get less data. This could be solved if there were a simply a rate limit enforced on the consumption of RNG data allowed per guest VM. There is further discussion of that as well.

The truth is that for most needs you can have reasonably secure encryption by simply having an ordinary PRNG source like /dev/urandom that’s properly initialized with random data. I suggest that you use that approach in your cloud deployments.

Check my post from today on the Rackspace Cloud blog. It covers several tips on planning ahead when writing a web-scale application.

Recently my clothes dryer had not been working well. Clothes inside were damp and warm rather than hot and dry at the end of a cycle. We called in the Maytag repair man. Actually I booked him on-line, and got an appointment just over 24 hours later. In all fairness, he was not a Maytag repairman, but someone from their authorized service network. He listened to my description of the problem and proceeded to disconnect the exhaust vent hose attachment at the back of the dryer. OMG it was totally packed with lint!

He explained that the dryer has an overheat safety sensor. When the exhaust temperature gets close to the point where it might catch lint on fire, it shuts down the gas, so the dryer cools off. With no vent, the dryer cooks the air in the exhaust path. My clothes were getting hot at the start of a cycle, and just tumbling after that. No wonder they would not dry! Happily I paid him for telling me that there was nothing to fix!

I’ve had this washer and dryer for almost a decade, and have never had a problem. Now that I had my first problem, and found that it was not even the appliance that had the issue, but simply that I had never cleaned out the exhaust path. I have since learned that this should be done regularly.

After a few minutes with my shop vac sucking lint out of the exhaust hose, inside the dryer exhaust plenum, and up the external vent pipe, everything was working perfectly again. First of all, I’m happy that the dryer had this safety feature so my house did not catch fire. According to the US Consumer Product Safety Commission people die from this all the time. Secondly, I’m thrilled that there was nothing mechanically wrong with my dryer. Thirdly, I’m looking forward to saving some costs on my Gas bill which will certainly decrease now.

I am such a happy Maytag customer! I used to laugh at the Maytag Repair Man ads. Not anymore. They have earned my complete respect for their safe and reliable appliances. When you buy a washer/dryer, you want reliability. Maytag is the real McCoy.