It's mostly likely using Field's metal (http://en.wikipedia.org/wiki/Field%27s_metal), Rose's metal (http://en.wikipedia.org/wiki/Rose_metal), Galinstan (http://en.wikipedia.org/wiki/Galinstan), or one of the other low-melting point low toxicity alloys, NOT mercury.
Electricity is fungible. If you use 1 kWh less of your local hydro power, then that 1 kWh will be transmitted to some place where they tend to use coal-fired plants. For instance, in the US, the Pacific DC Intertie (http://en.wikipedia.org/wiki/Pacific_DC_Intertie) carries hydro power from Oregon all the way south to LA; and LA gets half of its power from coal. If not for that long-distance DC link, it would be using a lot more coal power.
It isn't that there is overselling that is the problem, it's that there is *heavy* overselling. Comcast is promising gobs of bandwidth for very little money, yet they don't have the capacity to back it up. They probably based the amount they could oversell on estimates from pre-broadband usage patterns; it's not the customer's fault that Comcast made an incorrect assumption. If they've oversold so much that it is causing such bad problems, then advertise lower peak bandwidths, or stop accepting new customers. Cheating your existing customers is not a valid option.
As for the shortcomings of DOCSIS; the DSL specs allowed tuning which frequency bands are assigned to upstream vs. downstream. The phone company understood that traffic patterns can change, and that they need to be flexible. If the cable internet industry was incompetent/shortsighted when designing their specs, then they brought their troubles on themselves.
Shared co-ax has some advantages in that it does allow for very large peak bandwidth for individual users; it stinks in that it supports quite poor average bandwidth per user. For DSL, the expensive, super-high-speed links only have to go to the central offices; for cable internet, the whole loop has to operate fast. It was a good design for broadcasting TV; not so much for internet.
Not only that, but their own arguments support the view that they're massively oversold.
They say that they are only targeting a few users--that a "small minority" of people are hogging the bandwidth. If a small percentage (say, 2%) of your users can overload the network, that directly means you are heavily oversold (by 50x).
They admit to sending RST packets, but then claim that they don't forge packets. They're audacious enough to say that the people who say that the packets are forged are the liars. They also say RST packets are the only way, completely ignoring options like ICMP source quench, leaky bucket/token bucket filtering, or TCP's own congestion control reaction to dropped/delayed packets.
Whoever wrote Comcast's response has quite a pair.
Indeed, for individuals, pointing out security problems can be dangerous. It isn't very nice of them, but then again, most software vendors aren't nice either. Calling this blackmail is a bit of a stretch.
I agree that beating TCP by using UDP is hard; I've seen presentations about some of the tweaks the quants use on Wall Street to keep the update rates on their pricing models obscenely high, and it's clearly tricky stuff.
However, I think UDP for P2P is a lot easier, because the goal isn't "beat TCP", but "beat TCP when your ISP is purposely messing with your TCP". Also, the congestion control bits of TCP do hurt the raw bandwidth of one connection, so if your P2P app is the first to leave it out, you will be faster. Of course, once everyone is running without congestion control, the ISPs will have a real problem on their hands, because then everything will be choked full.
Just a note (perhaps you know this, but others may not), but the reason VPN works and SSH tunnels don't is because Sandvine targets long-lived TCP connections. By default, OpenVPN tunnels over UDP; the control messages for session handling is done by OpenVPN and is unreadable by intermediaries. With SSH tunnels, they can't read your data, but they can forge TCP control messages, which isn't encrypted.
Ironically, Comcast may be really hurting themselves in the long run; if it gets bad enough, P2P software writers will switch to UDP, and manually do the in-order/reliable delivery stuff themselves. TCP has a lot of fancy congestion control, and I doubt that the P2P writers will bother with it...
It seems that quite often, lawmakers listen (quite intently) to what government groups want the law to be. In this case, it is the city police who want this law. But the people don't benefit from it, just the police. The same thing holds for much of the Patriot Act; it is not a benefit for the people, but the FBI wanted it, and congress listened.
The biggest trouble isn't false alarms, terrorists, or corporate lobbying. The biggest trouble is that government listens to itself more that it listens to the people.
I'll do one better. Amazon should list the price that they would *like* to charge, next to the price that they are *forced* to charge. Keep a running total for every user of how much this law has cost them individually in their user profile, and promise that said amount will convert to store credit if and when it becomes legal to do so.
When the cost of stupid things are added up and shown to you in clear numbers, it makes it much more obvious the damage thus done.
QED. The purpose of the law is to encourage more bookshops to stock a wider selection of books,
And yet somehow Amazon manages to stock a wider selection of books than anybody. It seems to me that the purpose of the law is to keep the inefficient members of the union of French bookstores in business.
knowing they are not going to be undercut by a large conglomerate.
A conglomerate is a company which operates in more than one area of business. Last I checked, Amazon's only business was "retailer".
Where such agreements don't exist, there tend to be fewer bookshops
And hence fewer resources are wasted on an inefficient means of distributing books.
Consider the control rods in a nuclear reactor. They don't absorb all of the neutrons. They absorb some of the neutrons; enough to keep the overall reactivity down. To keep the reaction going, each neutron emitted spontaneously has to have a fairly high chance of reacting and creating another neutron. Control rods give each neutron a higher chance to be absorbed, which lowers the average "new" neutrons each spontaneous one emits, and so on.
Vaccination is the best control rod we have against communicable disease. Vaccines don't give perfect immunity; heck, even catching the disease doesn't provide 100% protection against catching it again. But it doesn't have to be perfect individually to give nearly perfect protection to a large population, *if* everyone is vaccinnated. Anyone who does get sick is unlikely to infect more people, if everyone around them is vaccinated. If the average number of people each patient infects is under 1, then the disease "fizzles". If a sufficiently high percentage of people are unvaccinated, though, the number of new cases each person causes will be over 1, and then you have an outbreak. The closer it gets to 1, the longer it will run (and the more people will get sick) before it finally fizzles. Being unvaccinated not only increases your risk, but it puts everyone around you at risk as well.
A concrete example of this was observed with influenza in Japan. Flu shots used to be mandatory for Japanese schoolchildren. Hence, few of them caught or spread the flu. In 1994, this requirement was dropped. Although young people tend not to die of the flu, old people do, and the schoolchildren were giving it to the elderly. Comparing mortality rates from before and after then change, it is estimated that every 420 vaccinated schoolchildren saved 1 elderly person from dying. Not getting sick, but dying. (A journal article about this is "The Japanese Experience with Vaccinating Schoolchildren against Influenza" by T. Reichert, N. Sugaya. et. at. in NEJM).
It doesn't take many unvaccinated people to cause a small outbreak; a handful of children in the same classroom who are unvaccinated can make the percentage coverage in that classroom too low. One of them gets sick, then nearly all of the unvaccinated ones do, then a good chunk of the vaccinated ones as well. Then their parents get sick, their parents co-workers, etc. People forget, but all of these "childhood diseases" we get immunized against used to be big killers; they aren't anymore because of vaccines.
People are scared of vaccines for three reasons. First, they seem to think that the plural of "anecdote" is "data". A few horror stories and they stop thinking rationally; they weigh the measured data of a 1 in 4300 risk of death if an infant catches whooping cough against a 1 in 110,000 risk of life-threatening adverse reaction to the vaccine, and choose the riskier course based on the stories they've heard. Second, anyone who has a bad reaction to a vaccine shouts it from the rooftops; how many people make impassioned cases about how when their son or daughter got vaccinated, *nothing happened*? All the widespread "stories" prove is that the stories spread well. Finally, people are bad at identifying patterns. Actually, they're good at it, just so good they see patterns where none exist. If I gave 1 million infants "disaccharide" pills, and told their parents about it, well, about 500 of those children would later be diagnosed as autistic, and the parents would blame those evil disaccharide pills. Except that disaccharide is just a fancy name for... sugar. For my next evil experiment, I'll give 1 million old people a small injection of dihydrogen monoxide, and see how many get Alzheimer's (I expect about 14 thousand).
These three things together create a hysteria about vaccines. People see bad things happening after the vaccine, and assume it is because of the vaccine. These people are hugely and disproportionately vocal about it. In turn, people give credence to anecdotes over d
Your only problem is the dynamic content. Any halfway competently written webserver can deal with a much heavier rush than slashdot, *if* it is serving static pages. Since you probably don't have the time to switch to a Rails implementation, take empaler's advice: try to move as many of the pages as you can to a static setup. Especially the ones that you feel the/. crowd (or Digg, or Fark, or whatever) are likely to read. Of course your truly dynamic content has to stay dynamic, but if you cut back on the hits to to cgi, things will get much better.
For OpenBSD specifically, well, they use a variant on blowfish for their hashing, called eksblowfish (for expensive key schedule). The key setup portion is purposefully slow; this severely limits speed of brute forcing attempts. Further, they use the salt in the key setup phase, which limits precomputation in the key schedule portion. Due the specific choices they made in designing eksblowfish, they need exactly 128 bits of salt, no more no less. Also, they are limited to 55 character passwords. Changing this limitation would require fundamental changes to the underlying blowfish algorithm, and is hence difficult to do. Essentially, they traded off the eks portion of their password hash (which makes it slow to brute force and resistant to future technological advances) for flexibility in password length and salt length. A paper detailing OpenBSDs password hashing is available from Usenix at http://www.usenix.org/events/usenix99/provos.html for free.
(As an aside, they could have done better. Of course, it is easy to say that after the fact, given people have had years to think about eksblowfish; they were then and still are now just about the best password hashing scheme one could concoct. A slight strengthening would be to use a good hash function (e.g. SHA-512) to pre-hash the password, then truncate that for use as the "password" in eksblowfish. This would allow arbitrarily long passwords, although it wouldn't allow more than 512 bits of entropy in the password, or any more entropy than eksblowfish currently takes)
For other hashing schemes, there is no point in using more salt than the size of your password hash. If your hash is only 128 bits (as is MD5), then for every salt longer than 128 bits, there is a shorter salt which collides with it. Since the real threats are dictionary and rainbow table, and attackers can take advantage of collisions, you cannot use salting to make the problem any harder than your hash length. There is a cost to longer password hashes, although it is relatively minor (and, per the argument of the OpenBSD crowd, you *ought* have an expensive hash).
On the other hand, even 64 bits of salt is quite paranoid anyway; it makes a dictionary attack a bit over 18 billion billion times harder. 128 bits is overkill already. Extreme overkill. It is far easier to just brute force the password (which salting doesn't help) than to use any precomptutation at that point. The average password has very few bits of entropy; this is a fundamental limit of passwords. It is hard to remember things with high entropy. Even long sentences don't have that much entropy, because sentences have a lot of predictability in them. Remembering enough to make Linux's 48 bit salts the weak link is pretty much impossible for your average user, and requires a special effort even for people who care.
You are correct that salting does not prevent nor make harder a brute force attack against one password.
It *does* breaks the Google attack, a precomputed dictionary, and rainbow tables, *even* if the attacker just wants *your* password.
Of these, rainbow tables is by far the most effective. Nobody computes their own rainbow tables. If I want to attack your hashed password, I'll download or buy a set of rainbow tables. Salting prevents this, because every salt value needs its own set of rainbow tables (or you have to include the salt rainbow table entries, which is approximately the same). Either way, using a 32-bit salt implies that to be equally effective, the total set of tables has to be 4 billion times larger. A 128 bit salt; well, you just can't create a set of rainbow tables for that. It just demolishes their effectiveness.
As you imply, there is a variant on salting which even makes plain brute forcing harder: don't store all of the salt. Of course this is (1) not widely deployed, and (2) imposes a high cost for legitimate use. Anyway, using repeated hash iterations is better, since you can't parallelize it.
You're implying that salting on UNIX makes attacking the hash infeasible, this is simply not true.
Salting doesn't make breaking hashes infeasible, but it makes the attacker work harder, and makes certain highly efficient attacks infeasible.
There are only 4096 different combinations in the salting algorithm in crypt() will use which a brute forcer can easily iterate.
And I completely agree that 12 bits of salt is insufficient in a modern world. Which is why MacOS 10.4 and up uses 32 bits of salt, most Linux implementations use 48 bits of salt, and OpenBSD uses (a rather paranoid) 128 bits. Since it doesn't require any more effort from the user, and only a tiny amount of resources, there's no reason not to use a large salt.
Salting a known algorithm is almost pointless because as I just described salted passwords can be just as easily defeated if you know the mechanism
If you have the password hashes they you have the salt too. Either way, brute forcing one password is no harder. But it means you have to work harder to do a whole list of passwords, because each password has to be attacked individually.
Salting also makes precomputation (pre-built dictionaries and rainbow tables) infeasible. Every bit of salt in essence doubles the amount of storage for your precomputation attack. This is (partly) why a fairly effective set of rainbow tables for LANMAN hashes take only 500ish MB, NTLM hashes take 8.5 GB, but even for the old Unix crypt() it would take at least 2 TB. And don't even think about trying any precomputation attacks against OpenBSD; even if the user was stupid and restricted themselves to 5 digit alphanumeric passwords, your rainbow table would consume more storage than exists. Salting makes you attack each password individually, and keeps you from doing any work ahead of time.
this is why NT doesn't include salt.
NTLM doesn't include a salt because (1) MS is trying to maintain a semblance of backwards compatibility with some ill-designed challenge response authentication mechanisms, and (2) they haven't learned the lesson that salting is a valuable strategy to make attacking hashes more difficult.
Also salt was used on UNIX only because when shadow passwords didn't exist the system had to be protected against users that had the same password and could easily read the password file to compare.
That is one reason why salts were used for old Unix crypt(). The other was to make precomputed dictionary attacks harder, which is still a valid use. Today, the best reason to use a salted hash is to avoid rainbow tables.
Really, the modern reason to use a salt is to prevent the type of attack the original poster used, and to prevent rainbow table attacks. Both of these are good attack techniques, and salting completely moots them.
Rainbow tables? Salting breaks it. Precomupted dictionaries? Salting breaks it. Brute force and compare against the whole pw list? Salting breaks it.
Salting is your friend. Long salts don't cost much, but make many attacks completely infeasible. Unix has been using salted passwords since forever. Yet nthash *still* doesn't include a salt.
List of #500 on the TOP500 by year
Year ..- RPeak . . . | Machine's owner and country | Make & Model
06/1998 - 15.0 GPLOPS | Southwestern Bell, USA. . . | HPC 6000, Sun
11/1998 - 20.5 GFLOPS | Koeln Universitaet, Germany | HPC 10000 Sun
06/1999 - 34.2 GFLOPS | CIEMAT, Spain . . . . . . . | T3E900 Cray
11/1999 - 38.4 GFLOPS | Bank, United States . . . . | HPC 10000 400 MHz, Sun
06/2000 - 51.2 GFLOPS | EDS, United States. . . . . | HPC 10000 400 MHz, Sun
11/2000 - 78.0 GFLOPS | Zurich American, USA. . . . | SP Power3 375MHz, IBM
Really, calling this a supercomputer is lame. It has only one 250GB disk; it will have utter crap IO performance. Most compute heavy jobs are also disk heavy because you want to checkpoint your intermediate results in case of a crash. Since there is only one disk, one machine must be serving it up to the others (NFS, ISCSI, whatever). It is clustered through gigabit ethernet, which will act as a limit on performance. They even skimped on the connection to the outside world and got a 100MBit card. "Real" clusters use Infiniband or Myrinet, both of which are optimized for high throughput with low latency and low contention. Gigabit is not. Linpack is rather kind to clusters; more finely grained parallel tasks will pay more for the poor linkup.
Also, with only 4 processors one could also build a 4-way SMP machine which would then not have to deal with any sort of message passing at all. You instead get one shared memory interface. It may be slightly NUMA, but the extra latency cost of hypertransport is amazingly low. Instead, by putting only one dual core die per motherboard, you have to jump through hoops to move work from one die to another, and pay really bad latency costs. You could also do better with a 2 quad-core processors on the same mobo (although you'd have to go Intel for now...). It's easier to program, supports finer grained parallelism, and allows potential savings on other parts.
I can get 2 quad-core Xeons at 2.4 GHz each and a 2 socket motherboard for $820 at newegg. They spent $980 on 4 dual-core 2GHz processors and 4 single socket motherboards. They also spent $240 on gigabit cards and the switch. So, for $400 less, I can have an SMP machine; one which probably has higher floating point performance as well. Rather than 4 cheap power supplies I can get one nice one (which is probably more efficient too). Further, I don't have to run 3 of my nodes diskless. Really, at this small scale a cluster is not the way to go.
Bad form to reply to myself, but here's links to relevant SCOTUS cases. Overall, the tone is about when one has a reasonable expectation of privacy.
Note that the links may require registration (findlaw seems to be a little random about that). You can also just google the case names.
SILVERMAN v. UNITED STATES, 365 U.S. 505 (1961) ---------- Ruling that using a "spike mike" to push against adjoining wall to listen in was illegal. The ruling makes a big deal that nobody expects a spike mike to be used, and that the people who were being listened to had a reasonable expectation of privacy.
KATZ v. UNITED STATES, 389 U.S. 347 (1967) ---------- Ruling that bugging a public phone booth without a warrant was illegal. The ruling makes a big deal that although the phone booth was transparent, it still blocks sound, and it was for the purpose of not being overhead that one enters a phone booth. Hence, there is a reasonable expectation of privacy.
DOW CHEMICAL CO. v. UNITED STATES, 476 U.S. 227 (1986) ---------- Ruling that a 2000 acre industrial site is not like the curtilage of a house, but is more like an open field, so using commercially available aerial photography is not illegal. The ruling considers that since anybody could overfly it isn't a big deal, and that the area is particularly large and open so one really can't expect privacy. The ruling briefly mentions that if advanced satellites were used, the search could have been illegal.
CALIFORNIA v. CIRAOLO, 476 U.S. 207 (1986) ---------- Ruling that naked eye observation from 1000 ft in an airplane in public airspace is not illegal. The ruling considers that anybody could fly over at 1000 ft, and that overflights aren't unusual, hence there shouldn't be an expectation of privacy.
FLORIDA v. RILEY, 488 U.S. 445 (1989) ---------- Ruling that naked eye observation from 400 ft in a helicopter in public airspace is not illegal. The ruling seems to make a big deal that nobody mentioned that 400ft helicopter overflights are unusual, and leaves open the question that if somebody did bring evidence that they were unusual, that the search may have been deemed illegal. However, given that anybody could have flown a helicopter at 400ft, it is legal.
Law enforcement can't just make arbitrary searches; that's what the fourth amendment is about. If you hold a reasonable expectation of privacy, then fourth amendment rights apply, even in the face of advancing technology. The use of infrared cameras to look for marijuana grow lights is illegal without a warrant, for example. Similarly, even though it is feasible for there to be a microphone planted inside a phone booth, you have a reasonable expectation of privacy inside phone booth. So, LEOs need to get a warrant before they can bug a phone booth.
Also, there are some traditional privacy rights which can interact in interesting ways. For instance, you have the same privacy rights in the area immediately around a house (the curtailage) as you would inside. The curtailage includes any areas under a roofing overhang, and any areas generally bounded by fences, hedges, and other physical obstructions which would prevent a ground-level observer from peeking in. So, even though your back yard is open to the sky, both aerial photography or satellite imagery requires a warrant. Viewing from a nearby tall hill doesn't.
Law enforcement can already use commercial satellite imagery (within 4th amendment limits), or their own aerial overflights (again, within limits) to get images just as readily as they could from the US government. For the scary things people are worried about, they can already do them if they are willing to break the law themselves. Using military satellites would be just as illegal.
Mostly, it looks like large investment institutions hold the bulk of SCO shares. Probably these are part of "total market" indexes and mutual funds. Since SCOX is still listed, they would still be a component of such funds.
The best I can tell, the insiders are mostly gone. The largest holder of SCO seems to be Glenn J Krevlin. There are some articles out there linking him to some other bad smelling companies; the phrase "smoke & mirrors" seems common. SCO sounds right up his ally.
FYI, there were 2.4 million shares of SCOX shorted as of July 10th. Today's volume was just short of 6 million shares. So, even if every single short position was closed today, it wouldn't even account for half of the volume.
Slashdot Mirror
From my Firehose post:
It's mostly likely using Field's metal (http://en.wikipedia.org/wiki/Field%27s_metal), Rose's metal (http://en.wikipedia.org/wiki/Rose_metal), Galinstan (http://en.wikipedia.org/wiki/Galinstan), or one of the other low-melting point low toxicity alloys, NOT mercury.
Electricity is fungible. If you use 1 kWh less of your local hydro power, then that 1 kWh will be transmitted to some place where they tend to use coal-fired plants. For instance, in the US, the Pacific DC Intertie (http://en.wikipedia.org/wiki/Pacific_DC_Intertie) carries hydro power from Oregon all the way south to LA; and LA gets half of its power from coal. If not for that long-distance DC link, it would be using a lot more coal power.
It isn't that there is overselling that is the problem, it's that there is *heavy* overselling. Comcast is promising gobs of bandwidth for very little money, yet they don't have the capacity to back it up. They probably based the amount they could oversell on estimates from pre-broadband usage patterns; it's not the customer's fault that Comcast made an incorrect assumption. If they've oversold so much that it is causing such bad problems, then advertise lower peak bandwidths, or stop accepting new customers. Cheating your existing customers is not a valid option.
As for the shortcomings of DOCSIS; the DSL specs allowed tuning which frequency bands are assigned to upstream vs. downstream. The phone company understood that traffic patterns can change, and that they need to be flexible. If the cable internet industry was incompetent/shortsighted when designing their specs, then they brought their troubles on themselves.
Shared co-ax has some advantages in that it does allow for very large peak bandwidth for individual users; it stinks in that it supports quite poor average bandwidth per user. For DSL, the expensive, super-high-speed links only have to go to the central offices; for cable internet, the whole loop has to operate fast. It was a good design for broadcasting TV; not so much for internet.
That analogy is terrible! Vuze is nothing at all like a cupholder; it's more like a heated seat.
Not only that, but their own arguments support the view that they're massively oversold.
They say that they are only targeting a few users--that a "small minority" of people are hogging the bandwidth. If a small percentage (say, 2%) of your users can overload the network, that directly means you are heavily oversold (by 50x).
They admit to sending RST packets, but then claim that they don't forge packets. They're audacious enough to say that the people who say that the packets are forged are the liars. They also say RST packets are the only way, completely ignoring options like ICMP source quench, leaky bucket/token bucket filtering, or TCP's own congestion control reaction to dropped/delayed packets.
Whoever wrote Comcast's response has quite a pair.
Indeed, for individuals, pointing out security problems can be dangerous. It isn't very nice of them, but then again, most software vendors aren't nice either. Calling this blackmail is a bit of a stretch.
I agree that beating TCP by using UDP is hard; I've seen presentations about some of the tweaks the quants use on Wall Street to keep the update rates on their pricing models obscenely high, and it's clearly tricky stuff.
However, I think UDP for P2P is a lot easier, because the goal isn't "beat TCP", but "beat TCP when your ISP is purposely messing with your TCP". Also, the congestion control bits of TCP do hurt the raw bandwidth of one connection, so if your P2P app is the first to leave it out, you will be faster. Of course, once everyone is running without congestion control, the ISPs will have a real problem on their hands, because then everything will be choked full.
Just a note (perhaps you know this, but others may not), but the reason VPN works and SSH tunnels don't is because Sandvine targets long-lived TCP connections. By default, OpenVPN tunnels over UDP; the control messages for session handling is done by OpenVPN and is unreadable by intermediaries. With SSH tunnels, they can't read your data, but they can forge TCP control messages, which isn't encrypted.
Ironically, Comcast may be really hurting themselves in the long run; if it gets bad enough, P2P software writers will switch to UDP, and manually do the in-order/reliable delivery stuff themselves. TCP has a lot of fancy congestion control, and I doubt that the P2P writers will bother with it...
It seems that quite often, lawmakers listen (quite intently) to what government groups want the law to be. In this case, it is the city police who want this law. But the people don't benefit from it, just the police. The same thing holds for much of the Patriot Act; it is not a benefit for the people, but the FBI wanted it, and congress listened.
The biggest trouble isn't false alarms, terrorists, or corporate lobbying. The biggest trouble is that government listens to itself more that it listens to the people.
I'll do one better. Amazon should list the price that they would *like* to charge, next to the price that they are *forced* to charge. Keep a running total for every user of how much this law has cost them individually in their user profile, and promise that said amount will convert to store credit if and when it becomes legal to do so.
When the cost of stupid things are added up and shown to you in clear numbers, it makes it much more obvious the damage thus done.
And yet somehow Amazon manages to stock a wider selection of books than anybody. It seems to me that the purpose of the law is to keep the inefficient members of the union of French bookstores in business.
knowing they are not going to be undercut by a large conglomerate.
A conglomerate is a company which operates in more than one area of business. Last I checked, Amazon's only business was "retailer".
Where such agreements don't exist, there tend to be fewer bookshops
And hence fewer resources are wasted on an inefficient means of distributing books.
Consider the control rods in a nuclear reactor. They don't absorb all of the neutrons. They absorb some of the neutrons; enough to keep the overall reactivity down. To keep the reaction going, each neutron emitted spontaneously has to have a fairly high chance of reacting and creating another neutron. Control rods give each neutron a higher chance to be absorbed, which lowers the average "new" neutrons each spontaneous one emits, and so on.
Vaccination is the best control rod we have against communicable disease. Vaccines don't give perfect immunity; heck, even catching the disease doesn't provide 100% protection against catching it again. But it doesn't have to be perfect individually to give nearly perfect protection to a large population, *if* everyone is vaccinnated. Anyone who does get sick is unlikely to infect more people, if everyone around them is vaccinated. If the average number of people each patient infects is under 1, then the disease "fizzles". If a sufficiently high percentage of people are unvaccinated, though, the number of new cases each person causes will be over 1, and then you have an outbreak. The closer it gets to 1, the longer it will run (and the more people will get sick) before it finally fizzles. Being unvaccinated not only increases your risk, but it puts everyone around you at risk as well.
A concrete example of this was observed with influenza in Japan. Flu shots used to be mandatory for Japanese schoolchildren. Hence, few of them caught or spread the flu. In 1994, this requirement was dropped. Although young people tend not to die of the flu, old people do, and the schoolchildren were giving it to the elderly. Comparing mortality rates from before and after then change, it is estimated that every 420 vaccinated schoolchildren saved 1 elderly person from dying. Not getting sick, but dying. (A journal article about this is "The Japanese Experience with Vaccinating Schoolchildren against Influenza" by T. Reichert, N. Sugaya. et. at. in NEJM).
It doesn't take many unvaccinated people to cause a small outbreak; a handful of children in the same classroom who are unvaccinated can make the percentage coverage in that classroom too low. One of them gets sick, then nearly all of the unvaccinated ones do, then a good chunk of the vaccinated ones as well. Then their parents get sick, their parents co-workers, etc. People forget, but all of these "childhood diseases" we get immunized against used to be big killers; they aren't anymore because of vaccines.
People are scared of vaccines for three reasons. First, they seem to think that the plural of "anecdote" is "data". A few horror stories and they stop thinking rationally; they weigh the measured data of a 1 in 4300 risk of death if an infant catches whooping cough against a 1 in 110,000 risk of life-threatening adverse reaction to the vaccine, and choose the riskier course based on the stories they've heard. Second, anyone who has a bad reaction to a vaccine shouts it from the rooftops; how many people make impassioned cases about how when their son or daughter got vaccinated, *nothing happened*? All the widespread "stories" prove is that the stories spread well. Finally, people are bad at identifying patterns. Actually, they're good at it, just so good they see patterns where none exist. If I gave 1 million infants "disaccharide" pills, and told their parents about it, well, about 500 of those children would later be diagnosed as autistic, and the parents would blame those evil disaccharide pills. Except that disaccharide is just a fancy name for... sugar. For my next evil experiment, I'll give 1 million old people a small injection of dihydrogen monoxide, and see how many get Alzheimer's (I expect about 14 thousand).
These three things together create a hysteria about vaccines. People see bad things happening after the vaccine, and assume it is because of the vaccine. These people are hugely and disproportionately vocal about it. In turn, people give credence to anecdotes over d
Your only problem is the dynamic content. Any halfway competently written webserver can deal with a much heavier rush than slashdot, *if* it is serving static pages. Since you probably don't have the time to switch to a Rails implementation, take empaler's advice: try to move as many of the pages as you can to a static setup. Especially the ones that you feel the /. crowd (or Digg, or Fark, or whatever) are likely to read. Of course your truly dynamic content has to stay dynamic, but if you cut back on the hits to to cgi, things will get much better.
For OpenBSD specifically, well, they use a variant on blowfish for their hashing, called eksblowfish (for expensive key schedule). The key setup portion is purposefully slow; this severely limits speed of brute forcing attempts. Further, they use the salt in the key setup phase, which limits precomputation in the key schedule portion. Due the specific choices they made in designing eksblowfish, they need exactly 128 bits of salt, no more no less. Also, they are limited to 55 character passwords. Changing this limitation would require fundamental changes to the underlying blowfish algorithm, and is hence difficult to do. Essentially, they traded off the eks portion of their password hash (which makes it slow to brute force and resistant to future technological advances) for flexibility in password length and salt length. A paper detailing OpenBSDs password hashing is available from Usenix at http://www.usenix.org/events/usenix99/provos.html for free.
(As an aside, they could have done better. Of course, it is easy to say that after the fact, given people have had years to think about eksblowfish; they were then and still are now just about the best password hashing scheme one could concoct. A slight strengthening would be to use a good hash function (e.g. SHA-512) to pre-hash the password, then truncate that for use as the "password" in eksblowfish. This would allow arbitrarily long passwords, although it wouldn't allow more than 512 bits of entropy in the password, or any more entropy than eksblowfish currently takes)
For other hashing schemes, there is no point in using more salt than the size of your password hash. If your hash is only 128 bits (as is MD5), then for every salt longer than 128 bits, there is a shorter salt which collides with it. Since the real threats are dictionary and rainbow table, and attackers can take advantage of collisions, you cannot use salting to make the problem any harder than your hash length. There is a cost to longer password hashes, although it is relatively minor (and, per the argument of the OpenBSD crowd, you *ought* have an expensive hash).
On the other hand, even 64 bits of salt is quite paranoid anyway; it makes a dictionary attack a bit over 18 billion billion times harder. 128 bits is overkill already. Extreme overkill. It is far easier to just brute force the password (which salting doesn't help) than to use any precomptutation at that point. The average password has very few bits of entropy; this is a fundamental limit of passwords. It is hard to remember things with high entropy. Even long sentences don't have that much entropy, because sentences have a lot of predictability in them. Remembering enough to make Linux's 48 bit salts the weak link is pretty much impossible for your average user, and requires a special effort even for people who care.
You are correct that salting does not prevent nor make harder a brute force attack against one password.
It *does* breaks the Google attack, a precomputed dictionary, and rainbow tables, *even* if the attacker just wants *your* password.
Of these, rainbow tables is by far the most effective. Nobody computes their own rainbow tables. If I want to attack your hashed password, I'll download or buy a set of rainbow tables. Salting prevents this, because every salt value needs its own set of rainbow tables (or you have to include the salt rainbow table entries, which is approximately the same). Either way, using a 32-bit salt implies that to be equally effective, the total set of tables has to be 4 billion times larger. A 128 bit salt; well, you just can't create a set of rainbow tables for that. It just demolishes their effectiveness.
As you imply, there is a variant on salting which even makes plain brute forcing harder: don't store all of the salt. Of course this is (1) not widely deployed, and (2) imposes a high cost for legitimate use. Anyway, using repeated hash iterations is better, since you can't parallelize it.
You're implying that salting on UNIX makes attacking the hash infeasible, this is simply not true.
Salting doesn't make breaking hashes infeasible, but it makes the attacker work harder, and makes certain highly efficient attacks infeasible.
There are only 4096 different combinations in the salting algorithm in crypt() will use which a brute forcer can easily iterate.
And I completely agree that 12 bits of salt is insufficient in a modern world. Which is why MacOS 10.4 and up uses 32 bits of salt, most Linux implementations use 48 bits of salt, and OpenBSD uses (a rather paranoid) 128 bits. Since it doesn't require any more effort from the user, and only a tiny amount of resources, there's no reason not to use a large salt.
Salting a known algorithm is almost pointless because as I just described salted passwords can be just as easily defeated if you know the mechanism
If you have the password hashes they you have the salt too. Either way, brute forcing one password is no harder. But it means you have to work harder to do a whole list of passwords, because each password has to be attacked individually.
Salting also makes precomputation (pre-built dictionaries and rainbow tables) infeasible. Every bit of salt in essence doubles the amount of storage for your precomputation attack. This is (partly) why a fairly effective set of rainbow tables for LANMAN hashes take only 500ish MB, NTLM hashes take 8.5 GB, but even for the old Unix crypt() it would take at least 2 TB. And don't even think about trying any precomputation attacks against OpenBSD; even if the user was stupid and restricted themselves to 5 digit alphanumeric passwords, your rainbow table would consume more storage than exists. Salting makes you attack each password individually, and keeps you from doing any work ahead of time.
this is why NT doesn't include salt.
NTLM doesn't include a salt because (1) MS is trying to maintain a semblance of backwards compatibility with some ill-designed challenge response authentication mechanisms, and (2) they haven't learned the lesson that salting is a valuable strategy to make attacking hashes more difficult.
Also salt was used on UNIX only because when shadow passwords didn't exist the system had to be protected against users that had the same password and could easily read the password file to compare.
That is one reason why salts were used for old Unix crypt(). The other was to make precomputed dictionary attacks harder, which is still a valid use. Today, the best reason to use a salted hash is to avoid rainbow tables.
Really, the modern reason to use a salt is to prevent the type of attack the original poster used, and to prevent rainbow table attacks. Both of these are good attack techniques, and salting completely moots them.
Rainbow tables? Salting breaks it.
Precomupted dictionaries? Salting breaks it.
Brute force and compare against the whole pw list? Salting breaks it.
Salting is your friend. Long salts don't cost much, but make many attacks completely infeasible. Unix has been using salted passwords since forever. Yet nthash *still* doesn't include a salt.
a bit is a base 10 unit
Good luck finding a 1 megabit memory IC that has only 1,000,000 bits of storage...It would be great if they also provided links to various federal and state fraud statutes...
And links to your state's AG office...
And little adwords ads on the side for local law firms.
List of #500 on the TOP500 by year
Year .
06/1998 - 15.0 GPLOPS | Southwestern Bell, USA. . . | HPC 6000, Sun
11/1998 - 20.5 GFLOPS | Koeln Universitaet, Germany | HPC 10000 Sun
06/1999 - 34.2 GFLOPS | CIEMAT, Spain . . . . . . . | T3E900 Cray
11/1999 - 38.4 GFLOPS | Bank, United States . . . . | HPC 10000 400 MHz, Sun
06/2000 - 51.2 GFLOPS | EDS, United States. . . . . | HPC 10000 400 MHz, Sun
11/2000 - 78.0 GFLOPS | Zurich American, USA. . . . | SP Power3 375MHz, IBM
Really, calling this a supercomputer is lame. It has only one 250GB disk; it will have utter crap IO performance. Most compute heavy jobs are also disk heavy because you want to checkpoint your intermediate results in case of a crash. Since there is only one disk, one machine must be serving it up to the others (NFS, ISCSI, whatever). It is clustered through gigabit ethernet, which will act as a limit on performance. They even skimped on the connection to the outside world and got a 100MBit card. "Real" clusters use Infiniband or Myrinet, both of which are optimized for high throughput with low latency and low contention. Gigabit is not. Linpack is rather kind to clusters; more finely grained parallel tasks will pay more for the poor linkup.
Also, with only 4 processors one could also build a 4-way SMP machine which would then not have to deal with any sort of message passing at all. You instead get one shared memory interface. It may be slightly NUMA, but the extra latency cost of hypertransport is amazingly low. Instead, by putting only one dual core die per motherboard, you have to jump through hoops to move work from one die to another, and pay really bad latency costs. You could also do better with a 2 quad-core processors on the same mobo (although you'd have to go Intel for now...). It's easier to program, supports finer grained parallelism, and allows potential savings on other parts.
I can get 2 quad-core Xeons at 2.4 GHz each and a 2 socket motherboard for $820 at newegg. They spent $980 on 4 dual-core 2GHz processors and 4 single socket motherboards. They also spent $240 on gigabit cards and the switch. So, for $400 less, I can have an SMP machine; one which probably has higher floating point performance as well. Rather than 4 cheap power supplies I can get one nice one (which is probably more efficient too). Further, I don't have to run 3 of my nodes diskless. Really, at this small scale a cluster is not the way to go.
Bad form to reply to myself, but here's links to relevant SCOTUS cases. Overall, the tone is about when one has a reasonable expectation of privacy.
c ourt=US&vol=365&invol=505
c ourt=US&vol=389&invol=347
c ourt=us&vol=476&invol=227
n avby=search&court=US&case=/us/476/207.html
n avby=search&court=US&case=/us/488/445.html
Note that the links may require registration (findlaw seems to be a little random about that). You can also just google the case names.
SILVERMAN v. UNITED STATES, 365 U.S. 505 (1961)
----------
Ruling that using a "spike mike" to push against adjoining wall to listen in was illegal. The ruling makes a big deal that nobody expects a spike mike to be used, and that the people who were being listened to had a reasonable expectation of privacy.
http://caselaw.lp.findlaw.com/cgi-bin/getcase.pl?
KATZ v. UNITED STATES, 389 U.S. 347 (1967)
----------
Ruling that bugging a public phone booth without a warrant was illegal. The ruling makes a big deal that although the phone booth was transparent, it still blocks sound, and it was for the purpose of not being overhead that one enters a phone booth. Hence, there is a reasonable expectation of privacy.
http://caselaw.lp.findlaw.com/scripts/getcase.pl?
DOW CHEMICAL CO. v. UNITED STATES, 476 U.S. 227 (1986)
----------
Ruling that a 2000 acre industrial site is not like the curtilage of a house, but is more like an open field, so using commercially available aerial photography is not illegal. The ruling considers that since anybody could overfly it isn't a big deal, and that the area is particularly large and open so one really can't expect privacy. The ruling briefly mentions that if advanced satellites were used, the search could have been illegal.
http://caselaw.lp.findlaw.com/scripts/getcase.pl?
CALIFORNIA v. CIRAOLO, 476 U.S. 207 (1986)
----------
Ruling that naked eye observation from 1000 ft in an airplane in public airspace is not illegal. The ruling considers that anybody could fly over at 1000 ft, and that overflights aren't unusual, hence there shouldn't be an expectation of privacy.
http://caselaw.lp.findlaw.com/scripts/getcase.pl?
FLORIDA v. RILEY, 488 U.S. 445 (1989)
----------
Ruling that naked eye observation from 400 ft in a helicopter in public airspace is not illegal. The ruling seems to make a big deal that nobody mentioned that 400ft helicopter overflights are unusual, and leaves open the question that if somebody did bring evidence that they were unusual, that the search may have been deemed illegal. However, given that anybody could have flown a helicopter at 400ft, it is legal.
http://caselaw.lp.findlaw.com/scripts/getcase.pl?
Law enforcement can't just make arbitrary searches; that's what the fourth amendment is about. If you hold a reasonable expectation of privacy, then fourth amendment rights apply, even in the face of advancing technology. The use of infrared cameras to look for marijuana grow lights is illegal without a warrant, for example. Similarly, even though it is feasible for there to be a microphone planted inside a phone booth, you have a reasonable expectation of privacy inside phone booth. So, LEOs need to get a warrant before they can bug a phone booth.
Also, there are some traditional privacy rights which can interact in interesting ways. For instance, you have the same privacy rights in the area immediately around a house (the curtailage) as you would inside. The curtailage includes any areas under a roofing overhang, and any areas generally bounded by fences, hedges, and other physical obstructions which would prevent a ground-level observer from peeking in. So, even though your back yard is open to the sky, both aerial photography or satellite imagery requires a warrant. Viewing from a nearby tall hill doesn't.
Law enforcement can already use commercial satellite imagery (within 4th amendment limits), or their own aerial overflights (again, within limits) to get images just as readily as they could from the US government. For the scary things people are worried about, they can already do them if they are willing to break the law themselves. Using military satellites would be just as illegal.
See http://finance.yahoo.com/q/mh?s=SCOX for a list of major holders.
Mostly, it looks like large investment institutions hold the bulk of SCO shares. Probably these are part of "total market" indexes and mutual funds. Since SCOX is still listed, they would still be a component of such funds.
The best I can tell, the insiders are mostly gone. The largest holder of SCO seems to be Glenn J Krevlin. There are some articles out there linking him to some other bad smelling companies; the phrase "smoke & mirrors" seems common. SCO sounds right up his ally.
FYI, there were 2.4 million shares of SCOX shorted as of July 10th. Today's volume was just short of 6 million shares. So, even if every single short position was closed today, it wouldn't even account for half of the volume.