There are some operational issues we should use some care around. This code will allow us to generate keys at a much higher burst rate than before, but we probably should use some care around server load and the randomness supply.

One thing we should do is expose the rdrand and aes cpu flags in the virts when their host provides them. With a newer OpenSSL this provides improved randomness and 2-3x better openssl performance. 

There may also need to be some work around our randomness management. There are real world attacks based around low startup entropy. 

OpenSSL uses /dev/urandom (which can run dry of entropy soon after system start and under heavy load) and the $HOME/.rnd file for randomness. (https://www.openssl.org/support/faq.html#USER1) ($HOME is /var/opt/opscode/opscode-erchef in EC, and /srv/oc_erchef/current in hosted.) Using the .rnd file provides better seed material in the event of depletion of system entropy, especially right after boot when the system randomness may be *very* predictable, and carrying over entropy from a previous boot can be helpful. Virtual hosts are especially vulnerable; early versions of the ubuntu VM system didn't provide the virts with entropy from the host on startup.

We should use care about the permissions of this file; our install scripts should make sure that the the $HOME/.rnd file is read/write by the erchef user, and not readable by anyone else. If we can't then our keys right after boot will be poor in a very hard to detect way.

It's probably worthwhile doing a bit more research and incorporating a usage note in the code. 

References:
https://www.openssl.org/support/faq.html#USER1
http://wiki.openssl.org/index.php/Random_Numbers

http://openssl.6102.n7.nabble.com/seed-RANDFILE-confusion-td19793.html