Carter inherited a disastrous economy, which resulted from a prolonged war funded by future earnings. When the bill came due at the end of the decade, the economy had massive problems. Sound familiar?

I see this logic repeated a lot, but it isn't correct. It's true that Windows has the vast majority of the market share, and is therefore an inviting target. But given that Macs have approx 10% of the market share in the US, you would expect 10% of the viruses to be written for the Mac. Virus writers use Macs too. However, only a few proof of concept viruses have ever been developed for OS X, that rate has not increased as the Mac as gained market share, and none have been successful in the wild. Therefore, it seem very unlikely that OS X is as vulnerable to viruses as Windows.

Note that not all exploits are viruses. Both Windows and OS X are vulnerable to other kinds of exploits. However, because OS X ships with almost no services enabled by default and does not require them to be enabled to be functional, it's much harder to attack a default OS X configuration. Additionally, there are some fundamental differences in the behavior of programs in general on OS X. For example, Windows has a 15 year history of programs running in the background in the system tray, and an entire ecosystem has been built up around supplying small utility programs for windows that potentially create new threats or open new vulnerabilities. OS X will refuse to run any code downloaded from the Internet or installed from an outside source unless the user permits it to run first (using signed code hashes to validate the executable). It's much harder to run exploit code when the user must approve it.

It's a bug that the FF developers don't believe exists. Please see https://bugzilla.mozilla.org/show_bug.cgi?id=620723.

To get a sense of how long it would take to find a particular key, consider:

The key has n bits, so there are 2^n possible keys that can be enumerated with those bits.

Each processor can test m keys per second. (I'm assuming each processor has the same performance, and ignoring latency between CPU nodes, I/O latency, or anything else that might slow the system down.)

You have access to p processors.

So the time to process all 2^n keys is:

(2^n)/p*m

Note that the value of m doubles once every 18 months (due to Moore's law), so to keep the key finding time constant, you must also add a bit every 18 months. (Adding bits is fairly cheap, but developing faster processors is not!) The value of p is not all that important because p increase linearly as you add more nodes, while n and m increase exponentially. To figure out how long of a key you need for a given algorithm, you simply need to determine the amount of time that you want to keep your data secret for, and choose a number of bits such that (2^n)/p*m is sufficiently large.

I'll let you plug in the numbers and work out the exact times for your favorite system for yourself. :-)

It depends on the algorithm used, the performance of the individual nodes, the number of nodes being used in the attack, etc. Botnets vary wildly in size and performance. The Chinese supercomputer is (most likely) composed of off the shelf Intel or AMD processors. If someone used hardware custom designed to run a brute force attack, it might run much faster. (That's how some of the RSA challenge cracks were done.)

"Is it theoretically possible to derive the server's private key from a session key? How about from multiple session keys?"

Shouldn't be if you are using a well designed algorithm! If you could, that would be a major hole.

Because (assuming that you don't trust the Chinese CA), they would have to use Google's private key in order to produce signed data that was tied to the identity asserted in the certificate issued by the CA that signed for Google.

If you trust a CA that is controlled by the attacker, you're toast. You have to ensure that you do not. (I don't think most people in the world have any idea what a CA is though, let alone how to tell their browsers which ones to trust, so the reality is that any CA's that Mozilla or Google or Microsoft or other browser makers trust (by including them in their browsers by default) are also "trusted" by you.

Yes. Actually, I am. :-)

Breaking modern encryption algorithms using current techniques would take somewhere around the lifetime of the universe. The number of computations required to break a well designed algorithm increase exponentially with the key length. You should always use an algorithm and key length that can be expected to protect your data for longer than the data will remain valuable.

As I indicated in my explanation below, being able to create a certificate does not mean that they can trick you into trusting their site. They must have a cert signed by a root CA that you trust. If you trust the Chinese CA, then you're stuck trusting its assertions. But if you don't, the attack can't work.

Certificates aren't used to encrypt anything. The certificate contains a set of assertions about the subject of the certificate, signed by the certificate issuer. One of those assertions is typically the subject's public key. All the certificate is claiming is that a certain public key is associated with a certain identity, where that identity is claimed by the certification chain starting at some root (in this case, the Chinese CA). If you trust a certain root CA, then you also must trust any assertions made by the children of that CA in the CA hierarchy. If you do not trust that CA, then you won't trust any certification paths that originate at that root.

So is a man in the middle attack possible, as you've described? No. Here's what would actually happen:

1) You request a secure page "https://mail.google.com"
2) Google's server sends you Google's certificate. This is signed (through some CA chain) by a root CA that you (presumably) trust. An attacker could also send you Google's cert, but the attacker doesn't have Google's private key, so anything they encrypt could not be decrypted using Google's public key.
3) You verify that certificate by validating the certificate chain to it. Note that even though China may have a root CA, it doesn't have the private key that was used to generate the certificate. (If China sent you such a cert, it would only validate against the Chinese root CA, which you would have to already trust!)
4) If the attacker attempts to do a man in the middle attack, they can pass you a certificate, but they can't generate data signed by Google, unless you trust China's root CA, because the attacker doesn't have Google's private key.

There are two problems here:

1) Can China redirect traffic through its network by advertising that it has the lowest cost routing path? (Apparently, yes.) This is a wormhole attack, and is well documented in research literature.

2) Can China record or alter any traffic that passes through its network? If the data is sufficiently well encrypted, it can not read that data, although it can record the cyphertext. The fact that China can issue a certificate does not mean that it can read *your* data. It only means that encrypted data sent to Chinese servers can be read by the holder(s) of the encryption keys used by those servers.

If you are sending data over the net, and want to protect it, be sure that it is encrypted. If you don't care, be aware that anyone might be able to monitor it, even governments of other countries. If you don't trust the Chinese root CA to certify the identity of servers that you go to, don't accept their CA's certificate as an authority for that purpose.

OS X will tell you all of this stuff in the system profiler. In fact, if you install RAM in a non-optimal configuration in a Mac Pro, it will automatically detect it and tell you how to correct the problem for best performance. In the laptops, there is no "wrong" configuration, unless you put the wrong type of RAM in, in which case that RAM slot is disabled or, in the worst case, the system won't boot (in which case UEFI wouldn't help you anyway).

And here is an article on this exploit technique:

http://www.dailytech.com/USB+Drive+Malware+Exploit+Windows+7+Flaw+in+Apparent+Espionage+Effort/article19065.htm