Let me put it to you simply. In order for Intel today to beat Inmos back then, a single core from a single Intel CPU would have to have greater horsepower than a Cray X-MP. That is the figure you'd have to beat in order for the largest possible tightly-coupled SMP box of modern Intel processors to be - in any sense - better than the largest-possible tightly-coupled SMP box of Transputers. Are you willing to make that claim?
All that the x64 proves is that backwards compatibility is a good thing. If you developed a wholly new architecture and allowed it to run x64 code at x64 speeds as an uploadable microcode extension, it would do just as well as any "native" x64 processor.
Alternately, if you had a wholly new architecture and wrote a binary-to-binary cross-assembler which appeared to "install" x64 code on the box but actually installed code rewritten for the new processor, it would also likely sell just as well as any "native" x64 processor.
Nobody WANTS an ix86 or x64, and only geeks even know what these even mean. What people want is their software to work and work well. They don't give a shit how.
And that is the part you are utterly ignoring. You are mixing up the desired end result with one and only one (inferior) method of achieving that result. There are no practical reasons for the x86's survival, there are only practical reasons for machines that can run x86 code, which is a very different thing altogether.
Depends on how you measure success. Intel has only innovated once - inventing the microprocessor. After that, it has merely borrowed off other people or used price-cutting to kill competitors via marketplace abuse. I don't call that success. I call that failure.
Depends on how you measure market dominance. And, indeed, what market. Intel has a lower marketshare in the HPC market today than Inmos did in 1984, so there exists a market where your statement is incorrect.
Immaterial. The x86 is a lousy architecture and adding onto it hasn't helped any.
Intel's latest stuff is certainly not the best that ever was. It has no support for content-addressable memory and no support for MIMD, it isn't asynchronous, it's not 128-bit, it doesn't use wafer-scale integration, it doesn't support HyperTransport (which is faster than PCI Express) and it can't do on-the-fly instruction set translation --- all these things have been done on other architectures, making those architectures superior in these respects to Intel's latest and greatest. Even though some of these things were being done by others when Intel's best offering was the 8080.
IBM's POWER7 not only comes close, it beats the crap out of the Intel clone of the AMD x64 design. Yes, Intel were forced to clone AMD's design because theirs stank.
As for "ever has", the IIT 8087 was two orders of magnitude faster than Intel's. The 64000 was not only better than the 8086, it was a LOT better. The Transputer was 32-bit and could scale to the thousands of cores in a single box when Intel was 16-bit with an absolute limit of one core on one CPU.
In fact, I would be willing to bet that a 16-way Intel box with the latest CPUs could still be beat in raw processing power AND addressable memory space by a hypercube of Inmos T400s dating to 1984. THAT was "the best stuff that ever was" and I challenge you to show me a single thing Intel can do better now than Inmos could do then.
There are a few add-ons for checking the strength of a cert as well - probably doesn't matter nearly as much, since the breach is through the vendor and not through a security hole, but it would not surprise me if there's a relationship between bargain-basement certs and bargain-basement security.
I've e-mailed you two alternatives you didn't list.
Yes, the tech isn't cheap. But look at it from this perspective - the cracks that have been publicised have involved hundreds of thousands of SSNs and other personal data being compromised or stolen. So far, there's been no big lawsuits, but it'd take just one class-action for the world to change. $100,000 would buy a beefy SSL appliance or $1 per victim in a lawsuit. Assuming a court would award more than $1 per person, it follows that a $100,000 appliance is remarkably cost-effective.
If you want transparency, you can always do it yourself. Why wait for Google? You've a list of tools right there that will tell you who is throttling, when, where, how, by how much, and maybe even what they had for breakfast.
What they are doing is re-inventing the Internet Weather stations that have existed for a decade or so. (Think MRTG but on a much larger scale and with rather more sophisticated output.)
Well, ok, they're maybe adding in the capabilities of the open-source pchar utility, which gives you the packet loss and maximum throughput of every hop between any two points on the net.
Tell you what, if Google is going to give a million bucks for a better-packaged MRTG + pchar + IRRToolset, I'll take the contract. May take me a little while to produce a uniform look-and-feel, clean some of the cruft from pchar, produce useful statistics showing exactly what, where and by how much traffic is being throttled. A week, maybe two, add one more for documentation, and a final one so I can have some R&R in Hawaii...
It's not like Georgia will do any better. It'll probably do a lot worse, take longer to do it, and will likely take side-payments by ISPs to conceal any throttling detected.
1) A CA is merely a person/organization that certifies that client X is who client X claims to be. PGP/GnuPG works just fine using the "web of trust" concept, whereby instead of having organization O tell you that you can trust them*, you decide who YOU trust to be able to make such a verification.
*Example: Verisign handed a hacker a copy of Microsoft's private keys for their SSL certificate because someone phoned them claiming to be a Microsoft employee. I'm not sure I'm inclined to trust Verisign as much because of that, but I've no means of requiring Verisign-signed certs be countersigned by someone else in the existing system.
*Example: Britain tried to restrict all PKI to three licensed institutions handling ALL key generation. Don't think they U-turned because the fans of PGP screamed blue murder. British parliament doesn't work that way. They changed course because Businesses screamed blue murder. Which tells me businesses have absolutely no objection to going into the CA business at some level, even if it's on a trivial scale.
2) 65,000 connections per second, 20,000 SSL connections per second, 10,000 SSL connections per second... You get the idea. Sure they cost money, but so does a lawsuit if data gets stolen. SSL does not improve anything about end-user experience or maintainability, you are correct. It does improve your chances of staying in business if you handle sensitive information - and, these days when data mining has become a fine art, a lot of data is becoming very sensitive.
3) Since an SSL appliance or SSL-enabled proxy can provide different names to different servers on the outside whilst providing different names and internal IPs on the inside, whose vanity does it appeal to? Most of those 30x that I saw were blatantly unaware that SSL appliances (with different certificates per target hostname) even existed, so I consider them inferior geeks.
Have you ever heard of the technique called "jamming"? It's a technique whereby you create so much noise that it is impossible to identify the signal.
Whilst cryptography is only used on things that are essential to encrypt, the signal is 100%. Everything identified as encrypted is worth sniffing and analyzing. If encryption became ubiquitous, the signal would drop to nearly 0%. An attacker cannot tell what is of value and what is not.
Who might these attackers be? Frankly, I don't give a rat's arse. No point in being paranoid about any given group. In fact, why be paranoid at all? Encrypt everything and you're safe (until the encryption is broken, at which point you simply upgrade the cypher).
If SSL (really TLS as SSL 3.0 is really becoming a dead protocol) can be broken, you must assume it already has been and that the only safe strategy is to get it broken in public so that it can be fixed. In other words, you want ubiquitous encryption and you want it as heavily tested as possible.
(This reminds me of a story. Apparently, Rolls Royce were not impressed with the reliability of their Merlin engine, so they'd take one at random, ramp it up to full power and leave it until something burned out or broke. The engineers would then disassemble the engine, find the underlying cause and fix it in the design. After about 10 or so iterations of this, they had one of the best engines ever built. An expensive form of QA, but one of the best, which is why cryptography uses that same basic method.)
1) SSL certificates are free. It's the ones signed by recognized root authorities that are not. There is, of course, nothing to stop you from becoming a recognized root authority and having the major browsers install your root cert in their browsers - Thawte did. They started off as a spin-off from Apache, making an SSL-tuned webserver - I think they called it Sioux. If they could, why can't you?
2) Apache is horribly expensive compared to TUX for static content. Apache 2.x is also horribly expensive compared to some of the high-performance webservers. But you're still going to use Apache. Unless you use Servlets, which are about as expensive on memory and CPU as you can get.
Actually, it's nowhere near as bad as everyone is making out. Sheesh, what a bunch of fussy fusspots.
You have a deliberate "mitm" (otherwise known as a proxy) that has ALL of the certs (or, indeed, just one cert, since the object is to encrypt traffic, not necessarily strongly authenticate it). It can be multi-homed or it can have virtual hosts, it really doesn't matter worth a damn. This front-end box then runs plain HTTP requests to the actual server(s) hosting the content within the network.
The advantage? A single SSL accelerator is relatively cheap. As the box is basically a router that SSLs on one side, you can go fairly low-end. All the number-crunching is done on the accelerator. The CPU is just comparing headers and copying data between interfaces. The total cost of such a machine is not zero, and you'd have to weigh it against the cost of packet sniffing and the cost of having to rebuild the system if an account got breached (think Sourceforge, the FSF, Fedora, amongst others), and the risk of this happening. Risk analysis is not a simple subject and most decisions ever made by anyone are based on naive risk analysis.
In the end, if the risk analysis says that a dedicated SSL proxy is cheaper than the cost of not having one, then you're an idiot if you don't get one. If the risk analysis says not having one is cheaper, well, enable opportunistic IPSEC on the firewall and let people encrypt that way if they so wish.
It's perfectly simple. The more wives the rich, moronic types have, the fewer women are left for the geeks. Since intelligence is (in part) hereditary, allowing polygamy reduces the national IQ every generation. Of course, the better solution would be to require everyone to date at least one geek before being allowed to marry, but good luck getting Congress to agree.
I dunno. The fringe fanatics have managed to stage events for the purpose of wrecking ACORN, NPR and the healthcare bill. I see no difficulty in a group of them getting together for the express purpose of not being hired as, say, marine biologists and then using the legal system to get the university to admit that this is because they were creationists (via cross-questioning or even through the pre-trial discovery process).
We can prove one-time pads (about as classical as you can get - anything more classical would have involved Ancient Greece) as being perfectly secure.
We can prove certain algorithms as quantum-insecure (RSA, for example).
The key length that was established as vulnerable was about 19 kilobits, but a 64 kilobit key - aside from being too large for any existant quantum computers - isn't even close to being attackable.
Although P = NP isn't proven/disproven in the general case, there was a recent paper which proved P = NP for a narrow set of problems. However, that isn't necessarily a problem. If you have a problem solvable in exponential or double exponential time, then P = NP won't help as that is purely a study of polynomial-time problems and exponential time is (a) different and (b) worse for the attacker.
Let's say you had a group of creationists who all applied together and all getting rejected. They then file a class action suit, citing the new law, and ensure that there's a secret recording or three from the interview which disproves the alleged reason. Creationists win, university goes bust.
In Texas, it might well pass and might well make it to the supreme court for the State. Let's face it - this is not a State known for multiculturalism, diversity of faith, or tolerance of difference. I'm not confident it wouldn't pass in the current Supreme Court, either, which is the really scary part.
But, yes, this does discriminate against all religions other than Creationist ones. It also discriminates against certain subjects - mythography, comparative mythology, comparative linguistics, prehistoric archaeology, paleontology and genetics all become MUCH harder if you reject the science on which these subjects are based. So does astronomy, geology, inorganic biochemistry, virology, microbiology and And where that rejection is based on anything other than Creationism, the candidate can lawfully be rejected in turn as inadequate to study/teach those subjects. However, if that candidate were a Creationist, then their rejection is inherently tied to their Creationist beliefs and the University or other institution CANNOT reject a candidate because of their Creationist views or anything stemming from those views.
In short, it would require places to hire unqualified individuals to teach subjects because the only reason they're unqualified is banned from being a criterion.
Given that no flaw in the algorithm is known and that the strength increases more rapidly with key length than standard pki (also in the article), there is substantial evidence that no such algorithm will exist (as the article also states).
Slashdot Mirror
Let me put it to you simply. In order for Intel today to beat Inmos back then, a single core from a single Intel CPU would have to have greater horsepower than a Cray X-MP. That is the figure you'd have to beat in order for the largest possible tightly-coupled SMP box of modern Intel processors to be - in any sense - better than the largest-possible tightly-coupled SMP box of Transputers. Are you willing to make that claim?
All that the x64 proves is that backwards compatibility is a good thing. If you developed a wholly new architecture and allowed it to run x64 code at x64 speeds as an uploadable microcode extension, it would do just as well as any "native" x64 processor.
Alternately, if you had a wholly new architecture and wrote a binary-to-binary cross-assembler which appeared to "install" x64 code on the box but actually installed code rewritten for the new processor, it would also likely sell just as well as any "native" x64 processor.
Nobody WANTS an ix86 or x64, and only geeks even know what these even mean. What people want is their software to work and work well. They don't give a shit how.
And that is the part you are utterly ignoring. You are mixing up the desired end result with one and only one (inferior) method of achieving that result. There are no practical reasons for the x86's survival, there are only practical reasons for machines that can run x86 code, which is a very different thing altogether.
Depends on how you measure success. Intel has only innovated once - inventing the microprocessor. After that, it has merely borrowed off other people or used price-cutting to kill competitors via marketplace abuse. I don't call that success. I call that failure.
Depends on how you measure market dominance. And, indeed, what market. Intel has a lower marketshare in the HPC market today than Inmos did in 1984, so there exists a market where your statement is incorrect.
Immaterial. The x86 is a lousy architecture and adding onto it hasn't helped any.
Intel's latest stuff is certainly not the best that ever was. It has no support for content-addressable memory and no support for MIMD, it isn't asynchronous, it's not 128-bit, it doesn't use wafer-scale integration, it doesn't support HyperTransport (which is faster than PCI Express) and it can't do on-the-fly instruction set translation --- all these things have been done on other architectures, making those architectures superior in these respects to Intel's latest and greatest. Even though some of these things were being done by others when Intel's best offering was the 8080.
IBM's POWER7 not only comes close, it beats the crap out of the Intel clone of the AMD x64 design. Yes, Intel were forced to clone AMD's design because theirs stank.
As for "ever has", the IIT 8087 was two orders of magnitude faster than Intel's. The 64000 was not only better than the 8086, it was a LOT better. The Transputer was 32-bit and could scale to the thousands of cores in a single box when Intel was 16-bit with an absolute limit of one core on one CPU.
In fact, I would be willing to bet that a 16-way Intel box with the latest CPUs could still be beat in raw processing power AND addressable memory space by a hypercube of Inmos T400s dating to 1984. THAT was "the best stuff that ever was" and I challenge you to show me a single thing Intel can do better now than Inmos could do then.
There are a few add-ons for checking the strength of a cert as well - probably doesn't matter nearly as much, since the breach is through the vendor and not through a security hole, but it would not surprise me if there's a relationship between bargain-basement certs and bargain-basement security.
I've e-mailed you two alternatives you didn't list.
Yes, the tech isn't cheap. But look at it from this perspective - the cracks that have been publicised have involved hundreds of thousands of SSNs and other personal data being compromised or stolen. So far, there's been no big lawsuits, but it'd take just one class-action for the world to change. $100,000 would buy a beefy SSL appliance or $1 per victim in a lawsuit. Assuming a court would award more than $1 per person, it follows that a $100,000 appliance is remarkably cost-effective.
http://www.kitchenlab.org/www/bmah/Software/pchar/
http://www.isc.org/software/irrtoolset
http://oss.oetiker.ch/mrtg/
http://www.caida.org/tools/
If you want transparency, you can always do it yourself. Why wait for Google? You've a list of tools right there that will tell you who is throttling, when, where, how, by how much, and maybe even what they had for breakfast.
http://www.internettrafficreport.com/main.htm
http://www.internettrafficreport.com/namerica.htm
Then there's the Weather Channel for geeks. That should give you a good indication of "unusual" packet losses, indicative of throttling.
http://www.noc.ucla.edu/weather.html
http://www.cgl.ucsf.edu/weather/weather.html
For more local weather on the tens, there's UCLA and UCSF.
There ya go, and it cost you rather less than the same information is costing Google.
What they are doing is re-inventing the Internet Weather stations that have existed for a decade or so. (Think MRTG but on a much larger scale and with rather more sophisticated output.)
Well, ok, they're maybe adding in the capabilities of the open-source pchar utility, which gives you the packet loss and maximum throughput of every hop between any two points on the net.
Throw in the Internet Routing Registry Toolset and you've a complete system.
Tell you what, if Google is going to give a million bucks for a better-packaged MRTG + pchar + IRRToolset, I'll take the contract. May take me a little while to produce a uniform look-and-feel, clean some of the cruft from pchar, produce useful statistics showing exactly what, where and by how much traffic is being throttled. A week, maybe two, add one more for documentation, and a final one so I can have some R&R in Hawaii...
It's not like Georgia will do any better. It'll probably do a lot worse, take longer to do it, and will likely take side-payments by ISPs to conceal any throttling detected.
1) A CA is merely a person/organization that certifies that client X is who client X claims to be. PGP/GnuPG works just fine using the "web of trust" concept, whereby instead of having organization O tell you that you can trust them*, you decide who YOU trust to be able to make such a verification.
*Example: Verisign handed a hacker a copy of Microsoft's private keys for their SSL certificate because someone phoned them claiming to be a Microsoft employee. I'm not sure I'm inclined to trust Verisign as much because of that, but I've no means of requiring Verisign-signed certs be countersigned by someone else in the existing system.
*Example: Britain tried to restrict all PKI to three licensed institutions handling ALL key generation. Don't think they U-turned because the fans of PGP screamed blue murder. British parliament doesn't work that way. They changed course because Businesses screamed blue murder. Which tells me businesses have absolutely no objection to going into the CA business at some level, even if it's on a trivial scale.
2) 65,000 connections per second, 20,000 SSL connections per second, 10,000 SSL connections per second... You get the idea. Sure they cost money, but so does a lawsuit if data gets stolen. SSL does not improve anything about end-user experience or maintainability, you are correct. It does improve your chances of staying in business if you handle sensitive information - and, these days when data mining has become a fine art, a lot of data is becoming very sensitive.
3) Since an SSL appliance or SSL-enabled proxy can provide different names to different servers on the outside whilst providing different names and internal IPs on the inside, whose vanity does it appeal to? Most of those 30x that I saw were blatantly unaware that SSL appliances (with different certificates per target hostname) even existed, so I consider them inferior geeks.
It's a good thing that my comments are of such high quality, then.
Have you ever heard of the technique called "jamming"? It's a technique whereby you create so much noise that it is impossible to identify the signal.
Whilst cryptography is only used on things that are essential to encrypt, the signal is 100%. Everything identified as encrypted is worth sniffing and analyzing. If encryption became ubiquitous, the signal would drop to nearly 0%. An attacker cannot tell what is of value and what is not.
Who might these attackers be? Frankly, I don't give a rat's arse. No point in being paranoid about any given group. In fact, why be paranoid at all? Encrypt everything and you're safe (until the encryption is broken, at which point you simply upgrade the cypher).
If SSL (really TLS as SSL 3.0 is really becoming a dead protocol) can be broken, you must assume it already has been and that the only safe strategy is to get it broken in public so that it can be fixed. In other words, you want ubiquitous encryption and you want it as heavily tested as possible.
(This reminds me of a story. Apparently, Rolls Royce were not impressed with the reliability of their Merlin engine, so they'd take one at random, ramp it up to full power and leave it until something burned out or broke. The engineers would then disassemble the engine, find the underlying cause and fix it in the design. After about 10 or so iterations of this, they had one of the best engines ever built. An expensive form of QA, but one of the best, which is why cryptography uses that same basic method.)
To answer 4, no. You can put a different SSL cert on a different port. 80/443 are not mandatory. The key is to hide the port stuff from the user.
1) SSL certificates are free. It's the ones signed by recognized root authorities that are not. There is, of course, nothing to stop you from becoming a recognized root authority and having the major browsers install your root cert in their browsers - Thawte did. They started off as a spin-off from Apache, making an SSL-tuned webserver - I think they called it Sioux. If they could, why can't you?
2) Apache is horribly expensive compared to TUX for static content. Apache 2.x is also horribly expensive compared to some of the high-performance webservers. But you're still going to use Apache. Unless you use Servlets, which are about as expensive on memory and CPU as you can get.
3) Why?
Actually, it's nowhere near as bad as everyone is making out. Sheesh, what a bunch of fussy fusspots.
You have a deliberate "mitm" (otherwise known as a proxy) that has ALL of the certs (or, indeed, just one cert, since the object is to encrypt traffic, not necessarily strongly authenticate it). It can be multi-homed or it can have virtual hosts, it really doesn't matter worth a damn. This front-end box then runs plain HTTP requests to the actual server(s) hosting the content within the network.
The advantage? A single SSL accelerator is relatively cheap. As the box is basically a router that SSLs on one side, you can go fairly low-end. All the number-crunching is done on the accelerator. The CPU is just comparing headers and copying data between interfaces. The total cost of such a machine is not zero, and you'd have to weigh it against the cost of packet sniffing and the cost of having to rebuild the system if an account got breached (think Sourceforge, the FSF, Fedora, amongst others), and the risk of this happening. Risk analysis is not a simple subject and most decisions ever made by anyone are based on naive risk analysis.
In the end, if the risk analysis says that a dedicated SSL proxy is cheaper than the cost of not having one, then you're an idiot if you don't get one. If the risk analysis says not having one is cheaper, well, enable opportunistic IPSEC on the firewall and let people encrypt that way if they so wish.
It's perfectly simple. The more wives the rich, moronic types have, the fewer women are left for the geeks. Since intelligence is (in part) hereditary, allowing polygamy reduces the national IQ every generation. Of course, the better solution would be to require everyone to date at least one geek before being allowed to marry, but good luck getting Congress to agree.
I dunno. The fringe fanatics have managed to stage events for the purpose of wrecking ACORN, NPR and the healthcare bill. I see no difficulty in a group of them getting together for the express purpose of not being hired as, say, marine biologists and then using the legal system to get the university to admit that this is because they were creationists (via cross-questioning or even through the pre-trial discovery process).
Wait, the router presumably has caches which are logical files, so even if the guy wasn't reading any files, he was writing to them.
We can prove one-time pads (about as classical as you can get - anything more classical would have involved Ancient Greece) as being perfectly secure.
We can prove certain algorithms as quantum-insecure (RSA, for example).
The key length that was established as vulnerable was about 19 kilobits, but a 64 kilobit key - aside from being too large for any existant quantum computers - isn't even close to being attackable.
Although P = NP isn't proven/disproven in the general case, there was a recent paper which proved P = NP for a narrow set of problems. However, that isn't necessarily a problem. If you have a problem solvable in exponential or double exponential time, then P = NP won't help as that is purely a study of polynomial-time problems and exponential time is (a) different and (b) worse for the attacker.
Duh! That's how Oracle intends to make the really big bucks.
There's a limit to how much material you can admit to being obscene before the tabloids get interested.
According to the GW conspiracy theorists, Scientific Scrutiny does indeed count as discrimination these days.
Let's say you had a group of creationists who all applied together and all getting rejected. They then file a class action suit, citing the new law, and ensure that there's a secret recording or three from the interview which disproves the alleged reason. Creationists win, university goes bust.
In Texas, it might well pass and might well make it to the supreme court for the State. Let's face it - this is not a State known for multiculturalism, diversity of faith, or tolerance of difference. I'm not confident it wouldn't pass in the current Supreme Court, either, which is the really scary part.
But, yes, this does discriminate against all religions other than Creationist ones. It also discriminates against certain subjects - mythography, comparative mythology, comparative linguistics, prehistoric archaeology, paleontology and genetics all become MUCH harder if you reject the science on which these subjects are based. So does astronomy, geology, inorganic biochemistry, virology, microbiology and And where that rejection is based on anything other than Creationism, the candidate can lawfully be rejected in turn as inadequate to study/teach those subjects. However, if that candidate were a Creationist, then their rejection is inherently tied to their Creationist beliefs and the University or other institution CANNOT reject a candidate because of their Creationist views or anything stemming from those views.
In short, it would require places to hire unqualified individuals to teach subjects because the only reason they're unqualified is banned from being a criterion.
Given that no flaw in the algorithm is known and that the strength increases more rapidly with key length than standard pki (also in the article), there is substantial evidence that no such algorithm will exist (as the article also states).