It is difficult to generate GPG keys in a virtual machine because of the lack of hardware interaction necessary to generate entropy in /dev/random. As a result, RNGD and HAVEGED can create random (or pseudo-random, depending on whom you ask) data to populate /dev/urandom which supplements /dev/random when creating secure keys. Unfortunately, in a container environment, write access to /dev/urandom is frequently unavailable. As a result, entropy is usually too low to create keys from within Cloud9, and users have no recourse. Because some users use Cloud9 as a CaaS/desktop alternative, the ability to generate keys can be important. Fortunately, the solution to this issue is quite simple. Running HAVEGED as a service can consistently generate entropy bits for /dev/urandom whenever the level of that file has dropped below a predetermined threshold. Since approximately 1000 bits are necessary to generate keys, and since multiple users rely on the same pool, I would recommend have HAVEGED consistently generate entropy whenever the threshold is below 10000.
That is a good point. Running it on a docker host actually allows it to generate entropy in the containers as well. I’ll try and get this changed shortly.
I should have predicated my initial observation with the recognition that the engineers at Cloud9 are certainly more knowledgeable about CaaS and IaaS than I am, so if I have made a mistake with my observation, I apologize for my ignorance. Regardless of whether my idea was viable or stupid, I appreciate your response, and I appreciate Cloud9, in general. (I am a professor, and I have seriously considered using Cloud9 for University for my classroom.)
On a separate note, I agree that RNGD and HAVEGED can create entropy in a container, but as far as I know (I am not really one for using texting abbreviations, such as AFAIK), that will only work if /dev/urandom is mounted a read-write within the container, which is not the default setting, so yes, one alternative to my suggestion would be to open up /dev/urandom so that container users could write entropy to it, but I cannot guess what other problems this could cause.
No, you’re spot on; I’ve been using haveged on my dev laptops for years to have more entropy in containers and VMs. Just didn’t hit an issue with lack of entropy yet within C9 and thought nothing of it. Hopefully no-one else will find a lack of entropy on c9 in the future
The default setting within docker does use the host for entropy; before making the change I did a quick test locally and when haveged was disabled I got ~100-200kb/s from /dev/random using
dd, and 8-9MB/s after it was re-enabled, so it doesn’t appear to need any specific settings for this.
We have quite a few classrooms using cloud9 these days, Harvard and Yale’s CS50 are one of the more well known ones. Feel free to send us an email at firstname.lastname@example.org if you want to talk about particulars in a classroom environment.