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

So basically, you are being invited to connect a USB device from an unknown source, with unknown code on it, to your machine. There have been many instances of people leaving USB sticks with exploit binaries around for people to find. You find the stick, stick it in your machine, and are promptly exploited. Regardless of whether the creator of the dead drops hasn't done this intentionally themselves (hopefully, they haven't), you have no idea what might have been placed on the sticks by others.

Different profs have different styles of teaching and communicating. Different technologies lend themselves well (or not) to different courses. PowerPoint slides work only so long as they are distributed to the students, but often cause the class to be taught too fast to take detailed notes. A blog wouldn't be useful at all for many courses. Would you find a blog on Roman history useful? What current events would the prof be responding to? How about a course on physics or compilers or crystal structures or genetics? How exactly would a blog help there?

Are the students technically inclined? If not, using technical resources may hurt more than it helps.

What really matters is if the prof can give clear explanations that students who learn in different ways can understand, whether or not the course is paced appropriately for the students, whether it is sufficiently advanced, but not so advanced that the students can't comprehend what is going on, whether assignments teach the students more of what they need to know, whether grading and feedback are timely and helpful, etc. It's not about throwing the latest technology at the students. That doesn't help at all unless it actually enhances how the students learn, or how effectively the prof can deliver the material!

Unfortunately this reasoning doesn't take into account that there are severe health and environmental costs from other forms of power production. When you take into account acid rain, global warming, air pollution, respiratory health effects, environmental damage from mining and oil drilling, and damage to the global ecosystem, Nuclear is likely to be far cheaper over the long term than most other forms of power. You have to look at the total cost of the technology, including obtaining and processing fuel, generating power, emissions, waste disposal, and costs to deal with externalities such as the effects mentioned above. When you take all of this into account, nuclear and solar are a bargain.

The first generation iPhone came out in 2007, not 2008. That's 3 years.

Death is a form of early termination. Doesn't death let you out of any contracts you are in by law?