Beta
×

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

Entropy Problems For Linux In the Cloud

kdawson posted more than 5 years ago | from the mehr-Zufälligkeit dept.

Security 179

CalTrumpet writes "Our research group recently spoke at Black Hat USA on the topic of cloud computing security. One of the interesting outcomes of our research was the discovery that the combination of virtualization technologies and public system images results in a problem for random number generation on guest operating systems. This is especially true for Linux, since its PRNG uses only a small set of entropy-gathering events, and virtual Linux images often generate SSH host keys within seconds of their initial boot. The slides are available; the PRNG vulnerability material begins at slide 63."

Sorry! There are no comments related to the filter you selected.

Slashdot is full of... (-1, Troll)

Anonymous Coward | more than 5 years ago | (#28935057)

Fags!

Re:Slashdot is full of... (0)

Anonymous Coward | more than 5 years ago | (#28936595)

Did you post that wirelessly from the gay bar you frequent? Nice to know that since you're here too, you're calling yourself gay. Unless you meant that Slashdot is full of cigarettes, or a bundle of sticks.

On an even more off-topic note, what's with "Anonymous Cowardon"? Fix that shit, Taco! AC users don't have a friend icon to create a space between the username and the "on [timestamp]", so you need to add one in.

Another advantage for TPM chips... (4, Informative)

Anonymous Coward | more than 5 years ago | (#28935067)

TPM chips have their bad things, but one thing they do offer is a cryptographically secure RNG. Its completely understandable not to trust it 100% completely, but you can use the random number stream it puts out as a good addition to the /dev/random number pool.

Re:Another advantage for TPM chips... (4, Insightful)

iYk6 (1425255) | more than 5 years ago | (#28935097)

Or you could plug in a microphone.

Any USB device (1)

StCredZero (169093) | more than 5 years ago | (#28935749)

Or you could plug in a microphone.

Assign all of he virtual servers a unique 256 bit ID. XOR that with 256 bits of input of any USB device that measures the real world, and send it through a hash algorithm. USB devices are easy for virtual servers to access.

Perhaps better, have a 256 bit seed for each server as above, but have the host server distribute 256 bits at startup time using a microphone run through a hash algorithm.

Re:Another advantage for TPM chips... (1)

tagno25 (1518033) | more than 5 years ago | (#28935763)

or a camera looking at the clouds

Re:Another advantage for TPM chips... (1)

profplump (309017) | more than 5 years ago | (#28935921)

That's even worse than the microphone idea -- every server and VM within 20 miles of you would have the same source for "random" data.

And that's ignoring the fact that clouds aren't random at all; they change in very well-understood ways given the wind, humidity, temperature, etc. The path, shape and density of clouds can be predicted in general terms a week in advance, and pretty specifically over the course of a few minutes.

Re:Another advantage for TPM chips... (1)

tagno25 (1518033) | more than 5 years ago | (#28936005)

I forgot <i> and </i>
it should be

or a camera looking at the clouds

or a randomness via what is happening where on multiple virtual machines being fed to a central server then striped and divided evenly between the virtual machines and hashed

Re:Another advantage for TPM chips... (1)

profplump (309017) | more than 5 years ago | (#28935887)

Unless you wanted all of the servers (and all of the VMs on each server) to have *different* entropy sources, which was the whole point of TFA. Unless you run a lot of single-device racks each in their own room you're just going to end up with an expensive way to get exactly the same "random" data on each machine.

There's also some correlation between things like disk activity and sound output of the machine; there may be some entropy available in the ambient sound -- it may even be chaotic -- but it's certainly not a source of random data.

Re:Another advantage for TPM chips... (1)

hairyfeet (841228) | more than 5 years ago | (#28935979)

there are plenty of free webcams that will let you look at...say the Eiffel tower, or even out at some guy's yard to watch his grass grow. Couldn't those free feeds be used to generate the random number?

Re:Another advantage for TPM chips... (1)

techno-vampire (666512) | more than 5 years ago | (#28936205)

Background sound in a server room is likely to be a fairly regular hum. Better yet is a geiger counter picking up background radiation.

Re:Another advantage for TPM chips... (4, Informative)

evanbd (210358) | more than 5 years ago | (#28936421)

You don't need a mic. The resistor noise on the sound card inputs is present and of secure quantum origin, regardless of whether a microphone is plugged in. The microphone noise is louder, but it's much harder to determine how much secure entropy is present. Why trust it when you don't have to? There's plenty available for most purposes without it. The Turbid [av8n.com] program does this in an efficient and secure manner (and they have a paper discussing the details, along with the relevant proofs, for the curious).

Re:Another advantage for TPM chips... (1)

Brian Gordon (987471) | more than 5 years ago | (#28935133)

TPM chips have their bad things

They do? It's secure crypto hardware.. what's evil about that? Yes you have scary evil like Palladium but you don't have to install it if you don't want to. And if machines take control you can always disable the device from the BIOS.. (given you don't care about any data which has encryption keys stored only in the module)

Re:Another advantage for TPM chips... (0)

Anonymous Coward | more than 5 years ago | (#28935365)

They do? It's secure crypto hardware.. what's evil about that?

The evil is presumably that it can't be verified. How do you verify the output of a hardware random number generator to determine if it really is random?

Re:Another advantage for TPM chips... (1)

wizzat (964250) | more than 5 years ago | (#28935399)

Seems like you would test it the same way you would test a RNG algorithm, if you suspected it wasn't random.

Re:Another advantage for TPM chips... (1)

xZgf6xHx2uhoAj9D (1160707) | more than 5 years ago | (#28935503)

Black box testing isn't all that productive for RNGs. You can check distribution and very simple patterns, but beyond that it's a major headache. White box testing makes things much easier. Yay source code!

Re:Another advantage for TPM chips... (3, Informative)

profplump (309017) | more than 5 years ago | (#28935857)

Most of the RNG chips publish pretty good specifications on the design of their entropy source, the amount of real entropy it provides, and the circumstances in which that entropy level might be reduced. There could be implementation or production errors or course, just like there could be runtime or compiler errors with software, but the design is available for perusal and has been analyzed.

For example, the Intel 82802:
http://www.cryptography.com/resources/whitepapers/IntelRNG.pdf [cryptography.com]

Re:Another advantage for TPM chips... (1)

drinkypoo (153816) | more than 5 years ago | (#28936011)

That's not true of TPM chips, whose insides are secret (unless you have a SEM.)

Re:Another advantage for TPM chips... (0)

Anonymous Coward | more than 5 years ago | (#28935849)

I am definitely for TPM chips and trusted hardware, but there is are valid concerns. There is a worry that if TPM chips become standard on machines, they would be used for a hardware DRM "stack", making PCs into closed machines just like consoles.

Once most PCs shipped with these, game companies would demand they be turned on and their software take ownership of the TPM as an "anti-piracy" measure.

Re:Another advantage for TPM chips... (1)

NotQuiteReal (608241) | more than 5 years ago | (#28935277)

or just write a script to check my favorite stock values... pretty random, as far as I can tell. But trending down :-(

Re:Another advantage for TPM chips... (1)

Tubal-Cain (1289912) | more than 5 years ago | (#28935645)

All my favorite stock values are ones with a lot of zeros after it. Too bad none of my stocks are at those values.

Re:Another advantage for TPM chips... (1)

Isao (153092) | more than 5 years ago | (#28935353)

TPM doesn't buy you anything in a VM - the virtualized environment has to trust the host that it's getting the correct certificates and data. The VM doesn't have direct access to the TPM, and the TPM won't export private keys. Also, that's only one set of keys per TPM, so multiple/portable VMs aren't realistic. I'm in favor of the tools TPM offers users (vice content producers) but I don't believe this is a good fit.

Getting creative (2, Interesting)

Brian Gordon (987471) | more than 5 years ago | (#28935085)

How about getting signed entropy from a trusted server on the network/internet? How about putting that microsecond-accurate system clock to use?

Re:Getting creative (0, Offtopic)

pitchpipe (708843) | more than 5 years ago | (#28935195)

Entropy Problems For Linux In the Cloud

Ponder this headline being read by a geek 50 years ago...

Re:Getting creative (3, Funny)

JWSmythe (446288) | more than 5 years ago | (#28935281)

    Well, clearly that "Linux" thing is a toxic gas weapon being used by the reds. Ya, I'd worry about them blowing up a chemical weapon in the clouds. They obviously got the technology from the Nazi's (no, not a candidate for Godwin's law).

    I don't know about you, but I'm grabbing my M1 Garand and heading down to the shelter under the house. Once that Linux stuff clears, I'll they'd better have thought twice about attackin' my good ol US of A.

    Well, you asked what they would have though 50 years ago, didn't you? :)

   

Re:Getting creative (1)

cheftw (996831) | more than 5 years ago | (#28935291)

Well clouds and entropy are old concepts and Linux is a name.

What a crap ponder.

Re:Getting creative (4, Interesting)

Brian Gordon (987471) | more than 5 years ago | (#28935587)

I think of some primitive post-human civilization struggling to industrialize amid the ruins of the heat-dead universe.

There's little solid matter left. Nobody really knows why; the legends tell of ancient, sprawling empires releasing great monsters that consume worlds and deliver energy to fuel their eons-old wars in the cold between the stars. Several human colonies survived the Last Scourge. One even knew something of their people's history. This colony of merchant-scholars thrived in an old space-borne city drifting about a great lightyears-long dust cloud inexplicably left untouched by the wars. The city was old, very old, built by a generation of master engineers who etched their likenesses in the great canvases of the city's impervious white construction. Quiet machinery lurked untouched in the mysterious depths of the undercity, seen only by outcasts wandering alone through those vast echoing chambers.

The city provided everything the civilization needed. Somehow (so much seemed like magic to them that even the usually-curious humans grew bored of speculation) their reservoirs filled with water, their air recycled, and their waste disappeared down bottomless shafts. All of their needs were filled, but they craved expansion and exploration. They were able to harvest some limited chemical energy from the food supplied by the city, and build using scrap. Still, entropy was a problem in the dust cloud of Linux. ....

Re:Getting creative (1)

bucky0 (229117) | more than 5 years ago | (#28936225)

I'll bite. that's an interesting story. where's it from?

Re:Getting creative (1)

jamesh (87723) | more than 5 years ago | (#28936135)

"w00t" is what I imagine the geek would be thinking.

Doesn't SSH use OpenSSL? (0)

Anonymous Coward | more than 5 years ago | (#28935103)

OpenSSL has a cryptographically secure random number generator. I know not everything uses it but doesn't (Open)SSH?

In the article are they just talking about the kernel random generator? I wouldn't trust that thing, even the "secure" one.

Re:Doesn't SSH use OpenSSL? (5, Informative)

morgan_greywolf (835522) | more than 5 years ago | (#28935205)

OpenSSL has a cryptographically secure random number generator. I know not everything uses it but doesn't (Open)SSH?

No. By default, OpenSSH will use the system's pesudo-random number generator, but you can also make it use prngd [sourceforge.net] or EGD (the Entropy Gathering Daemon) instead. Whether either are more "secure" than the kernel's built-in RNG I am not qualified to say.

Hardware support.... (1)

DrYak (748999) | more than 5 years ago | (#28935445)

Whether either are more "secure" than the kernel's built-in RNG I am not qualified to say.

Well, it depends on the hardware, as the kernel has drivers for various hardware RNG featured on some CPUs or virtualized source of randomness provided by the host.

Re:Hardware support.... (1)

Joce640k (829181) | more than 5 years ago | (#28935815)

Um, the article is discussing multiple virtual machines with identical disk images so "hardware support" is moot.

Here's a novel RNG (0)

Anonymous Coward | more than 5 years ago | (#28935107)

The number of molecules in Cmdr Taco's nacho-warrior farts !! This can range from a few thousand on a mild day, to say 4 BILLION on a down and dirty day. I know, I know, and you don't want to know how I know.

Re:Here's a novel RNG (0, Troll)

turbidostato (878842) | more than 5 years ago | (#28935203)

"The number of molecules in Cmdr Taco's nacho-warrior farts !! This can range from a few thousand on a mild day, to say 4 BILLION on a down and dirty day."

Sorry to point that out but you are understimating Cmdr Taco's farts by some orders of magnitude: it's more TRILLIONS (10^12) on a mild day up to a TRILLION OF TRILLIONS OF TRILLIONS (in the order of 10^24) on a funny day.

"I know, I know, and you don't want to know how I know."

I can sware I learn it on a book and nowhere else.

Re:Here's a novel RNG (1)

turbidostato (878842) | more than 5 years ago | (#28935485)

Troll!? Whoever modded me troll has to have a look at the Avogadro's number and its relationship with this thread.

Re:Here's a novel RNG (1, Insightful)

Anonymous Coward | more than 5 years ago | (#28935639)

Care must be taken when joking on Slashdot. It's not your fault, but you probably should have linked to Avogadro's Number [wikipedia.org] in your first post. Even dead simple jokes must be sufficiently documented to avoid getting modded down.

Why is this done in software at all? (3, Interesting)

BadAnalogyGuy (945258) | more than 5 years ago | (#28935115)

Why can't the CPU contain a register which holds a random number which is updated with every clock cycle?

Fuck off faggot (-1, Troll)

Anonymous Coward | more than 5 years ago | (#28935147)

Because your mom is a nigger-loving kike

Re:Why is this done in software at all? (2, Insightful)

bradkittenbrink (608877) | more than 5 years ago | (#28935157)

That's like asking "Why can't they add a DWIM opcode to the instruction set?"

Re:Why is this done in software at all? (0)

Anonymous Coward | more than 5 years ago | (#28935219)

Its a perfectly valid question.

Hardware makers are meant to make stuff that people actually use in the real world. Since random number generation is such a fundamental concept, why don't all CPU's have one built in... The OS is free to ignore it, say if it uses a poor implementation.

Compare it with the CAS instruction, MMX/Altivec or even GPU's in general - they are built to meet the market demand.

Re:Why is this done in software at all? (4, Insightful)

bradkittenbrink (608877) | more than 5 years ago | (#28935407)

So, I was mostly just giving him shit because of his name. If you want a more serious debate, here's my best shot: The instructions you described are all relatively easy to define a generally useful specification. My main point was that every application has differing standards of randomness that are required. Do you need real quantum-mechanical randomness, or just a CSPRNG? How many bits of random data do you need, and how frequently? I'm assuming that the request is for real quantum-mechanical randomness. I find it hard to imagine defining a good spec for such hardware component, especially since the vast majority of applications don't actually require quantum-mechanical randomness, and the ones that do are likely to have very specific requirements. Anyways, besides the fact that it's tough to come up with good requirements for such a feature, I bet it's really tough to implement as well. I know just barely enough about about hardware implementations to be dangerous, so someone who knows for real, please correct me if I'm wrong. Anyways, circuits that exhibit quantum-mechanical randomness are, as far as I know, essentially the same as circuits that cause metastability [wikipedia.org] in transistors. Because of the need to control for such problems, implementing such circuits on the same die as a normal digital circuit would likely be very expensive in terms of both die area and yield.

Re:Why is this done in software at all? (4, Informative)

ShadowRangerRIT (1301549) | more than 5 years ago | (#28935181)

First, the cost of computing truly random numbers is way too high for that, unless you are performing an iterative approach to random number generation (and then you have the problem of predictability). It could be done, but you'd be pumping a lot of hardware into computing values that would be thrown away 99.9%+ of the time.

Secondarily, if your PRNG algorithm is broken, you're stuck replacing the hardware. At least a bad software PRNG can be replaced.

That said, hardware PRNG is provided in many modern systems by a TPM [wikipedia.org] . It lacks the performance problems associated with your solution, since it only generates random numbers on demand. It still has the problem of a potential exploit being discovered leading to expensive hardware upgrades, but to my knowledge that has not been a problem to date.

Re:Why is this done in software at all? (3, Insightful)

Timothy Brownawell (627747) | more than 5 years ago | (#28935347)

Why can't the CPU contain a register which holds a random number which is updated with every clock cycle?

First, the cost of computing truly random numbers is way too high for that

Computers are deterministic. Truly random numbers cannot be computed, they can only be provided by special hardware (something that can measure shot noise or thermal noise, a camera pointed at a lava lamp, a movement detector in Schrodinger's cat's box).

Secondarily, if your PRNG algorithm is broken, you're stuck replacing the hardware.

That's why you don't do pseudo-random numbers, but real randomness from thermal noise or shot noise or some other quantum effect (cats and lava lamps don't fit on ICs).

That said, hardware PRNG is provided in many modern systems by a TPM.

And at some level, the randomness generator on the TPM almost certainly has an interface of "read this special register every X clock cycles" (because how else would you interface with your special hardware?).

It lacks the performance problems associated with your solution, since it only generates random numbers on demand.

If it's implemented in hardware (as it must be, to get true randomness), it's always running and there is no "on demand".

It still has the problem of a potential exploit being discovered leading to expensive hardware upgrades, but to my knowledge that has not been a problem to date.

That would be because it's a RNG instead of a PRNG.

Re:Why is this done in software at all? (1)

hardburn (141468) | more than 5 years ago | (#28935609)

That's why you don't do pseudo-random numbers, but real randomness from thermal noise or shot noise or some other quantum effect (cats and lava lamps don't fit on ICs).

A small radiation source/detector, like the ones in smoke detectors, can work just fine for this purpose. Since radiation is the result of quantum interactions, the output is truly random due to the nature of the universe.

Re:Why is this done in software at all? (1)

drerwk (695572) | more than 5 years ago | (#28935949)

While the radiation is random, the measurment being so depends on a perfect detector.

Re:Why is this done in software at all? (3, Interesting)

Timothy Brownawell (627747) | more than 5 years ago | (#28935217)

Why can't the CPU contain a register which holds a random number which is updated with every clock cycle?

Some do have something like that [via.com.tw] , although it's only about 800kbps instead of 4 bytes per cycle.

Re:Why is this done in software at all? (1)

hardburn (141468) | more than 5 years ago | (#28935585)

There are CPUs (or more often, chipsets) that provide RNGs, along with a few other hardware implementations of crypto algorithms. Most of them are meant for smaller computers, though, like the VIA C3. I wish they were more widespread and used.

Re:Why is this done in software at all? (1)

profplump (309017) | more than 5 years ago | (#28936003)

Many do. VIA has had CPU-integrated dual-oscillator hardware RNGs for a long time. Intel firmware hubs also commonly contain a hardware RNG, as do other motherboard architectures.

They aren't very fast sources of random data -- it's actually pretty hard to get truly random data, even outside the world of desktop CPUs -- but they are fast enough to provide a relatively long seed for a PRNG within seconds of boot. Assuming you use a reasonable PRNG, providing a truly random seed is sufficient to let the PRNG generate a high-speed sequence of data random enough for most practical applications, and certainly is unpredictable enough to protect against the situations described in TFA.

Surely Not. (2, Insightful)

lobiusmoop (305328) | more than 5 years ago | (#28935125)

Generating SSH keys involves interaction via at least keyboard and possibly mouse at a terminal. Surely that basic permise is enough to provide enough entropy for the pseudo-random generator. Also, the date and time (as sources of random) can't be virtualized of course.

Not surely (3, Interesting)

Kaseijin (766041) | more than 5 years ago | (#28935189)

Generating SSH keys involves interaction via at least keyboard and possibly mouse at a terminal.

SSH host keys are often generated automatically when the init script notices there aren't any.

Re:Surely Not. (1)

SanityInAnarchy (655584) | more than 5 years ago | (#28935591)

Generating SSH keys involves interaction via at least keyboard and possibly mouse at a terminal.

If you use PuTTY, yes. OpenSSH, at least, doesn't require anything in particular, just a sufficient amount of entropy. On a properly configured system, moving a mouse or banging randomly on the keyboard might feed entropy -- but then, so would plugging a microphone into the sound card, or any number of other things.

And as Kaseijin mentions, this is about host keys. Especially in a virtualized environment, you can't assume any sort of human interaction when these keys are generated.

Re:Surely Not. (1)

marcansoft (727665) | more than 5 years ago | (#28935865)

Last I checked the date and time are anything but random.

The main problem with cloud computing (0, Funny)

Anonymous Coward | more than 5 years ago | (#28935127)

is that it doesn't exist. It's a farce, a meaningless buzzword, just like web 2.0.

A more appropriate word would be servers.

Re:The main problem with cloud computing (0)

Anonymous Coward | more than 5 years ago | (#28935183)

true.

Re:The main problem with cloud computing (1)

chelsel (1140907) | more than 5 years ago | (#28935241)

AC, let me guess... you work for a cloud computing company, but not in marketing :-)

Re:The main problem with cloud computing (1)

SanityInAnarchy (655584) | more than 5 years ago | (#28935613)

Like Web 2.0, it has at least one or two specific meanings. The problem is getting specific -- a little knowledge is a dangerous thing, and managers can be very fuzzy (clouded?) about "cloud computing" if they don't understand the difference between calling Gmail a "cloud app" and calling Amazon Web Services a "compute cloud".

Re:The main problem with cloud computing (1)

brusk (135896) | more than 5 years ago | (#28935633)

Cloud computing is real, and some of the biggest computers in the world are devoted to it. Climate modeling is a very difficult problem and we still don't have it nearly right.

Parse Error (0)

Anonymous Coward | more than 5 years ago | (#28935141)

"it's": expected adjective; found verb instead

Much ado about nothing. (5, Funny)

Facegarden (967477) | more than 5 years ago | (#28935173)

All this complaining over random numbers is silly. All you really have to do is use 5. It's just as random as any other number, and it's easy to generate a 5.
-Taylor

Re:Much ado about nothing. (1)

turbidostato (878842) | more than 5 years ago | (#28935223)

"and it's easy to generate a 5"

And you can generate it at any random point in time too.

But somehow, being as random as anyone else, I prefer 42.

Re:Much ado about nothing. (0)

Anonymous Coward | more than 5 years ago | (#28935397)

I wish I thought of that.

Re:Much ado about nothing. (5, Funny)

BobisOnlyBob (1438553) | more than 5 years ago | (#28935421)

This only proves how easy it is to generate a (5, Funny).

Re:Much ado about nothing. (2, Funny)

hannson (1369413) | more than 5 years ago | (#28935493)

int getRandomNumer()
{
        return 4; // chosen by fair dice roll.
// guaranteed to be random.
}

Re:Much ado about nothing. (1)

martas (1439879) | more than 5 years ago | (#28935611)

no the true random number is 9 [archive.org]

Re:Much ado about nothing. (1)

tylerni7 (944579) | more than 5 years ago | (#28935859)

http://xkcd.com/221/ [xkcd.com]
It's cool, it's different because you used a 5.

Re:Much ado about nothing. (1)

jefu (53450) | more than 5 years ago | (#28935881)

No, the only true random number is 17. This was asserted by several mathematicians who used several lines of reasoning (one rather like this [flickr.com] ). Then you get the random sequence 17,17,17... and the random rational 0.17171717... and lots of other perfectly good random numbers. Though you probably shouldn't use them as a source for cryptographically strong random numbers.

Re:Much ado about nothing. (2, Insightful)

jamesh (87723) | more than 5 years ago | (#28936167)

Interesting that both Dilbert (years ago) and xkcd (more recently) both contain a comic with a similar joke...

Re:Much ado about nothing. (1)

sam0737 (648914) | more than 5 years ago | (#28936641)

Hell! I have been using 42 for long. And you know that's the Answer to Life, The Universe and Everything, including but not limited to generating Random Number I suppose.
I bet it works better than 5.

Big problem, but addressable (3, Interesting)

lamber45 (658956) | more than 5 years ago | (#28935201)

The nice thing about Linux is that you can develop whatever entropy-producing process you want and write its output to /dev/urandom to add more entropy to the pool. For instance, a boot script could issue an HTTP request to a website backed by a hardware random-number generator (access-control to only machines in the cloud by IP range). It is something to be worried about, though.

Java code that does cryptography or generates UUIDs (in the hope that they will be a truly universal key for something) operates under similar problems. JavaScript is even worse; all it has is the time, perhaps the user's window-size (not very random if maximised) and mouse-movements, and the built-in random() method, which is not expected to be of cryptographic quality.

Re:Big problem, but addressable (1)

gd2shoe (747932) | more than 5 years ago | (#28935765)

Interesting idea, though I would recommend HTTPS (pre-shared self signed cert would be sufficient for in-house use). If predictability is the problem you're trying to avoid, you want to skirt the packet sniffers.

By the way, why write to /dev/urandom, and not /dev/random? Doesn't /dev/urandom act as a front for /dev/random except when the entropy pool is empty (at which point it goes pseudo-random). Just curious.

Re:Big problem, but addressable (5, Informative)

CalTrumpet (98553) | more than 5 years ago | (#28935963)

Actually, /dev/random and /dev/urandom have their own, separate secondary pools that are fed off of a main pool when entropy is "depleted" in the second level pools. This is an area of research for us as well, since Linux's entropy estimation algorithm fails in situations where the timing deltas of entropy gathering events (IRQs and disk IOs) are actually predictable, so it's possible that the second level pools are not being refreshed at appropriate times.

If you write to /dev/urandom, it goes into the primary pool by tradition. This is what the rc scripts do on bootup with the random seed file on disk.

BTW, it's absolutely the wrong solution to get entropy from another source on the network (for many reasons, but one is that you can't do a secure HTTPS handshake without, you guessed it, unguessable random numbers). The whole point here is that we are looking for a way for 500 Linux instances on EC2 to have different entropy pools before the kernel completes boot. The only possible solution is for the hypervisor (Xen for Amazon) to provide a simulated HW RNG that pulls entropy from a real HW RNG or from an entropy daemon in the hypervisor.

The best way to learn about Linux RNG basics is Gutterman et. al. Analysis of the Linux Random Number Generator [iacr.org] . Several of the issues they describe have been addressed, such as their PFS concerns, but their description of the entropy pools is still accurate.

Linux has a paravirtual entropy driver (5, Insightful)

Anthony Liguori (820979) | more than 5 years ago | (#28935227)

CONFIG_HW_RANDOM_VIRTIO enables it. It's been there for quite a while.

We could easily support it in KVM but I've held back on it because to really solve the problem, you would need to use /dev/random as an entropy source. I've always been a bit concerned that one VM could starve another by aggressively consuming entropy.

lguest does support this backend device though.

Re:Linux has a paravirtual entropy driver (1)

42forty-two42 (532340) | more than 5 years ago | (#28935395)

Why not set a rate limit on entropy consumption then?

Re:Linux has a paravirtual entropy driver (1)

19thNervousBreakdown (768619) | more than 5 years ago | (#28936063)

I guess you could set it as an option, but the threshold between a useful amount of entropy and what it would take to starve another is often overlappng, so it wouldn't be much help in any but the most controlled situations--which is exactly when you wouldn't need the option.

Re:Linux has a paravirtual entropy driver (0)

Anonymous Coward | more than 5 years ago | (#28935903)

We could easily support it [...] but I've held back on it because to really solve the problem [...]

Wow. I've seldom seen such a clear example of Voltaire's maxim that "the perfect is the enemy of the good."

Re: (0)

Anonymous Coward | more than 5 years ago | (#28936159)

In Linux, it's not possible for one application to starve another of entropy. (At least, on my computer. I'm using Debian unstable). To check, try this:
1. Open 2 xterm windows (or 2 ttys, or whatever).
2. In the first window, type: cat /dev/random
3. Watch the gibberish on the screen.
4. Type the same thing in the second window.
5. Now, hit the ctrl and shift keys repeatedly, and move the mouse, to generate entropy.
6. You should see more gibberish in both windows, showing that neither one gets starved.

Re: (1)

hitmark (640295) | more than 5 years ago | (#28936431)

try scaling that up, and see where it ends up...

Re:Linux has a paravirtual entropy driver (1)

Chandon Seldon (43083) | more than 5 years ago | (#28936371)

Wouldn't it be sufficient to use the host random pool as a seed for some sort of strong PRNG?

Easy enough to fix.. (0)

Anonymous Coward | more than 5 years ago | (#28935251)

As part of cloning the image just do this:

dd if=/dev/urandom of=/target/var/lib/urandom count=1 bs=4096

There. Fixed it for you. Works better if the VM server has a high volume entropy source, but even if not it is still pretty damn good.

evidence that cloud is a fad? (2, Interesting)

noric (1203882) | more than 5 years ago | (#28935283)

I'd like some evidence that cloud computing is a fad. Tens of thousands of companies, in dozens of industries, do not list "computing hardware, availability, and capacity management" as a core competency, making them prime cloud customers.

Re:evidence that cloud is a fad? (0)

Anonymous Coward | more than 5 years ago | (#28935363)

The cloud is pants.

Re:evidence that cloud is a fad? (2, Insightful)

jellomizer (103300) | more than 5 years ago | (#28935451)

It is a tool in the bucket. That what it is. There will be a huge growth spurt, then they realize that it won't solve everything. Then they will cut back and still use it until they find something better.

Support via "Guest Additions"? (2, Insightful)

Just Brew It! (636086) | more than 5 years ago | (#28935317)

Seems to me this could be solved via the "Guest Additions" module that most virtualization packages recommend you install in the guest OS. Use the GA to inject some entropy from the host system into the guest system's entropy pool. The host CPU's TSC register would probably be an excellent source.

who cares? (-1, Troll)

Anonymous Coward | more than 5 years ago | (#28935383)

besides the gays no one cares about linsux.

Re:who cares? (0, Offtopic)

LordLimecat (1103839) | more than 5 years ago | (#28935603)

Its a sign of failure when noone even bothers to mod you troll...

Re:who cares? (1)

Just Brew It! (636086) | more than 5 years ago | (#28935981)

Umm... what?

Either we've had an honest misunderstanding here due to my not being entirely clear (which I'd be more than happy to straighten out), or you're a clueless moron. Unless you're willing to clarify why you consider me a "troll", I have no choice but to assume the latter.

Re:who cares? (1)

jamesh (87723) | more than 5 years ago | (#28936189)

The host CPU's TSC register would probably be an excellent source.

Actually, if 636086 reads the xen mailing lists then it's probably a subtle joke.

Re:who cares? (1)

Just Brew It! (636086) | more than 5 years ago | (#28936341)

No, seriously. The TSC counts raw host CPU clock ticks. I/O interrupts and CPU cache misses on the host should effectively de-correlate it with anything going on in the guest VMs. On a host with many guest VMs it only gets better, since the patterns of host I/O interrupts and guest VM timeslices will be even less predictable.

As long as it is not relied on as a continuous source of high quality entropy (i.e. it should be used to seed the pool, just like things like mouse movement etc. are used now), it ought to be a significant improvement.

Re:who cares? (1)

Just Brew It! (636086) | more than 5 years ago | (#28936391)

...and if you're worried about someone running a guest VM and using the host TSC value as the basis for some sort of attack on the RNGs of other similar VMs running on the same host, just run the TSC value through a hash function on the host side, before passing it to the VM. As long as the hash function is effectively one-way, you can't glean any information which might be useful in an attack on "sister" VMs.

Eh? (3, Interesting)

ledow (319597) | more than 5 years ago | (#28935471)

If you "need" cloud computing, then you're bright enough to install an entropy daemon on one of the machines and maybe even slap a hardware-based RNG on it (probably worth sourcing a VIA or similar just for this purpose, to be honest). It's not hard.

Anything else, your "randomness" really doesn't matter and the standard entropy will be just fine.

Re:Eh? (1)

Chandon Seldon (43083) | more than 5 years ago | (#28936415)

Bullshit. Any network connected host *needs* to be able to generate unguessable random numbers. Otherwise, that host might as well be a member of a botnet already.

Does it really matter? (0)

Anonymous Coward | more than 5 years ago | (#28935511)

If a random number generator is supposed to be random, won't one rng have the same chance to generate the same numbers as another in a given set?

No one wants to make money off the Interwebs! (2, Insightful)

zullnero (833754) | more than 5 years ago | (#28935631)

"The term cloud computing is useless" said Stamos. "It's way overused. It's mostly about gathering venture capital or selling your products."

Yes. Because no one on the Internet has any use for gathering venture capital or selling products.

It IS an overused term, but you're not testing some product or how people are using it, you're really just testing the security models of various operating systems to determine which are more ready to support those concepts that people grouped together and called "cloud computing". There were a lot of various concepts that were grouped together that comprised the "Net 2.0" concept too...and that cliche was just as derided for being overused. And yet, websites that aren't all ajaxed up or don't use css seem pretty old-fashioned these days.

That said, the question I have is how ready for those "cloud computing" concepts is Windows, really? How much of that security model is using the proper approach to securing a transaction instead of just shutting down that path altogether?

Definition of Cloud skewed (2, Informative)

smueller (520174) | more than 5 years ago | (#28935747)

This is not a "cloud" problem. This is a virtual server and image problem. Clouds have nothing to do with virtual servers. If you use a service like NewServers.com, you can get dedicated physical servers for your cloud, on-demand and at hourly prices.

Re:Definition of Cloud skewed (1)

CalTrumpet (98553) | more than 5 years ago | (#28936523)

While the origin of the issue is the virtualization layer, it is more specifically a cloud problem because most IaaS/VPS providers use standard images with a public random seed file, so everybody's machine initializes up to the same state (RTC + random seed + handful of interrupts).

GoDaddy VPS - SSH keys identical (1)

seifried (12921) | more than 5 years ago | (#28935951)

I did a system wipe and rebuild (re-installs CentOS from scratch) and SSH'ed in and... got no warning. The system's SSH keys were identical as the previous build. Needless to say I generated a local set and uploaded them.

Re:GoDaddy VPS - SSH keys identical (1)

Darkk (1296127) | more than 5 years ago | (#28935977)

Does this happen every time or just at random? (Excuse the pun).

FTA... (4, Funny)

NotBorg (829820) | more than 5 years ago | (#28935999)

"This falls somewhere between a very big deal and irrelevant," says Wagner.

I'm glad he cleared that up for me.

HotBots random number generator (1)

Animats (122034) | more than 5 years ago | (#28936227)

There's a simple random number generator based on a radioactive source [fourmilab.ch] on-line. That can be accessed through a Java app, and the hardware info needed to build one of your own is on line. There are commercial random number generators. [comscire.com] USB, even. A serious data center should have a few of these.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?