Hacker News Reader

Regarding entropy sources for guest virtual machines, the host can expose a random number generator device to the VM. This is an option in KVM: http://libvirt.org/formatdomain.html#elementsRng

Modern Intel x86 processors now have a hardware RNG built in, so even if the host boots without any devices, you have a source of entropy.

(Incidentally, KVM defaults to /dev/random which might create a DoS vulnerability if a guest exhausts entropy.)

Interesting. Do you know if any cloud providers do this? (DigitalOcean uses KVM so it would be a possibility.)

Exposing hardware RNGs to guest VMs would be great; entropy in guests is pretty lousy in general, not just at first boot (though obviously at first boot it's at its very worst).

We've run into the /dev/random problem when doing heavy SSL traffic. We had to pipe in sources of entropy. It was a janky solution, but wasn't as janky as it might sound.

If you need more entropy for SSL traffic than a headless server that sees very little I/O load has available, I've found http://www.vanheusden.com/te/ useful in the past. The ~800 bits/sec is produced in our tests isn't massive, but it was considerably than the machines we used it on could generate from the kernel's usual sources on these machines. It claims to produce valid results in VMs too, and given the way it works it might be perfectly valid to scale is some way simply by running more than one copy.

If you want more than that in a cheap Heath Robinson manner (Americans: think Rube Goldberg if you are unaware of Heath, their work came from very similar inspirations) then many SoC solutions have a built-in RNG of sufficient quality for general cryptographic use and some solutions expose them easily. If you enable the relevant module a Raspberry Pi can provide up to ~550,000 bits/sec when asked to, for instance, which if one-off cost is a factor beats paying a few hundred dollars or more for a USB device providing the same sort of rate.

Another solution that we are happy with at least is http://www.issihosts.com/haveged/

Based on the HAVEGE research http://www.irisa.fr/caps/projects/hipsor/

Are you referring to the hardware RNG in TPMs? I thought they were very low bandwidth in terms of entropy, would that be a problem on first boot?

True, but much less of an issue than just leaving the same version of keys in place. In case you're curious, here's how the cloud-init library generally used for ec2 and ec2 compatible clouds works: https://github.com/number5/cloud-init/blob/master/cloudinit/...

Absolutely - baking the same private key into images is much, much worse (and in my opinion a pretty embarrassing thing for a cloud provider to do by accident).

In my experience, 'haveged' [1] has worked out really well for generating entropy on headless servers. It could be scripted into a provider's base distribution to include the haveged binary and run haveged before generating the SSH host keys.

[1] http://freecode.com/projects/haveged

It seems like booting up would actually be a great time for generating a decent amount of entropy, what with all those devices starting starting up from a relatively unpredictable physical state (temperature etc.), hard drives spinning up, and so forth. I'm kind of surprised that the Linux kernel doesn't exploit that.

> I'm kind of surprised that the Linux kernel doesn't exploit that.

I wouldn't say "surprised", more that I wonder why and if there's maybe a good reason for it--that seems more interesting than the notion of surprise to me, anyway :)

Especially considering pretty much everything I've heard about entropy-generation over the years mentions that getting entropy just after boot is a difficult problem.

I'm assuming there must be some truth to that, so your surprise is my curiosity for the explanation why that probably wouldn't work (yes I'm assuming it won't work, sorry, but I really think otherwise they'd be using it :) ). Does anyone know?

Surprise is a useful emotion for noticing that your model needs updating. There's no need to suppress the emotion - better to notice it. This is a kind of core principle in rationality - sort of the little sister of noticing confusion[1]. I think I'm pretty well trained at noticing surprise and using at as a signal to look for more information, and that was, in fact the purpose of my comment.

I don't post comments to demonstrate my cleverness (I hope). I post to tell about an interesting experience, make a careful argument, answer a question about which I'm knowledgeable, or solicit feedback. An expression of surprise for me is a solicitation for information. I was hoping someone with more domain knowledge would have some insight that I could integrate into my model. I realize that some people do just post comments to show their cleverness, and there's no way you could have known my intent without knowing me, so that feedback is well taken. I'll try to be clearer in the future about my intent.

I absolutely agree that what I said probably wouldn't work - no need to apologize! The prior probability for P(simple solution not used by experts | simple solution obvious to a non-expert) is low.

[1] http://lesswrong.com/lw/if/your_strength_as_a_rationalist/

Okay that makes a lot of sense. The way LessWrong uses the word "surprise" there is a little bit different than how it's used in day-to-day language, where it also carries a (subtle) value judgement, as opposed to being exclusively rational signal that ones model needs updating. Hence my confusion.

now I doubt we'll get an expert with domain knowledge to jump in after five days though :)

Even so, the boot sequence of a VM guest is generally straightforward with very little entropy.

It's slow, and manual, but this gives me one more reason to like prgmr, at least for my little side projects. You generate the keys, and send the public key to Luke. Your only access to the control layer is via public_key auth from that key you generated. Presumably on a laptop, with gobs of entropy available.

I believe you're confusing SSH host keys with the keys used for user authentication. The private SSH host key has to reside on the server, so it's either being generated on the server or you're sending Luke a private key.

But I agree this sounds like a good way to handle user authentication.

as much as I appreciate the plug, that key I ask you for? that's to get you into the admin interface on my side. I don't mess with the ssh keys within your image. (host keys are auto-generated on first boot, just like a real server, which has the 'generating keys in a low-entropy environment' problem described above. The image doesn't come with anything in the authorized_keys file; though actually, I could pretty easily adjust the creation script to put the key you sent me in the authorized_keys file of root... but I don't really know the 'right' way to do that; everyone has preferences, so I leave it up to the user.)

We've actually talked a lot about trying to write a xen driver to share a hardware entropy device, but it hasn't gone anywhere. (I mean, xen has 'vtpm' - a virtualized Trusted Platform Module. And nobody uses that, so why not a vrandom?)

I was interested in providing entropy as a service, but I couldn't validate the proposition with the obvious customer segment (i.e. cloud HVM operators, whether public or private).

Essentially, the trust bar for entropy is set so high that no-one who understood the product enough to want it, was willing to trust it enough to actually use it.

(It's not just for SSH keys; random values are required for e.g. SSL connection setup, too)

Sounds like most cloud-providers could just undercut your business by enabling such solutions locally though. I'm not sure how stable the business would be unless you were going to guarantee more entropy than they could locally generate.

Sure, but they're not actually doing it, are they...

Ah, also: by "HVM operators" I didn't mean AWS, Linode, Digital Ocean etc; I meant the admins of virtual machines running on their platforms, plus anyone running a private cloud or even someone with just a bunch of Xen/KVM boxes in a DC.