I'd imagine physically shred the SSDs back into sand? When I've needed to destroy an SSD, I've just taken a power drill to the flash chips.

Yes, TrueCrypt implies windows.

The parent implied that his use of Linux and ecryptfs somehow protected him from this type of attack, which really it doesn't, just this particular implementation of this attack.

My point is, that other full disk encryption implementations are typically vulnerable to the same sort of attack, that is the encryption key is going to be stored in memory.

There are in fact tools to extract keys over firewire(or other methods) for a variety of operating systems, not just Windows and TrueCrypt, consider Inception

Well a few points...

Well, you can use swap partitions, if they're encrypted. There are other ways to get a memory dump as well, you know. There are various nefarious ways to do this, if you are clever ;)

But what makes you think that if an attacker were able to get a memory dump of your system somehow(perhaps via firewire as an example), that ecryptfs on Linux would fare any better than TrueCrypt with regards to extracting the key from said memory dump.

The choice of operating system isn't really relevant here...

I'd consider TOR exit nodes to be fully monitored, so obviously you'd want to take all of the steps above as well, when browsing over TOR.

Encrypt everything, make life as difficult as possible for those who would snoop your traffic. You mention Firefox plugins, perhaps you should also be using the HTTPS Everywhere plugin: https://www.eff.org/https-everywhere

Also make sure you are using the SSL Observatory function, this should at least help prevent MITM type attacks against you.

Indeed there were some open usenet servers back in the early 2000s. I know when I was at Teleglobe in the early 2000s, we ran several open(read-only) usenet servers and we carried as much as alt.binaries.* as we could, we didn't have a very long retention time..but hey you weren't paying either ;)

Remember when all the crackers could be charged with was, "Theft of Electricity"? Now this is actual real theft of electricity.

Good and bad points, Andro. Plenty of felons get jobs

Oh I didn't say they couldn't get jobs, well paying ones? Doesn't sound like it. Ex-cons certainly are more willing to work for less pay. However when you have people underemployed or underpaid, recidivism certainly is a possible outcome. Your example of the luggage thieves, if they were getting paid better, they'd probably be a bit less likely to be stealing on the job. Pay people well enough. But don't take my word for it: http://news.illinois.edu/news/12/0730wagepremium_ClaraChen.html

Evidently, some organizations prefer felons.

Perhaps so, they might be willing to work for less pay, given their ex-convict status, makes them perhaps a slightly more desperate than average workforce.

I don't have any issues with giving people job skills at all, I just don't trust that the motives behind the people doing the training are 100% altruistic. They want a labor force that can be easily manipulated to work long hours for cheap. Ex-convicts fill that role nicely, as do H1B workers and new graduates.

What's the difference between an office with beds, a gym, a cafeteria(as seen as some sprawling corporate campuses) and a prison?

I guess when H1B workers just weren't cheap fucking enough, no, they need to use prison labor now too? Oh and good luck on getting a job with a felony record paying anything more than minimum wage, but I guess that is the point.

It was only a matter of time before anti-drone warfare came about. This happens with every new piece of weaponry, the quest for the anti-weapon. They don't call it an arms race for no reason.

This guy(who I won't name, you know who you are), was once writing some PHP code for some webapp. Well in app, he had some delete links and he hadn't finished the authentication code apparently, so googlebot crawled is site, followed all of the delete links and completely wiped out his database.

Of course, you can keep googlebot away from your crappy code with robots.txt too...

Not to mention the power systems for the entire DC area are too important to allow any outages no matter how short.

Bahaha...the power goes out in the DC area all the freaking time. Pepco is notorious for power outages in DC. They blame the "dense tree canopy of the city" or something retarded. Ask anyone who's lived there for a while.

The DC metro area has suffered major outages, the remnants of Hurricane Isabel knock out most of the power and water in Fairfax County, Virginia as well.

Anything important in the DC metro area and well everywhere else, is going to have both battery and generator backup power, knowing that grid power can and does fail all the time.

Too important my ass...the power reliability in DC was like living in a third world country.

Ram is considered volatile memory, meaning it loses its info when power is turned off.

Stick a battery on the drive with the RAM instead of flash? You know, battery backed cache is not a new thing. Usually you see it for RAID controllers. There isn't any reason a small battery could be installed with the drive, recharged via the power supply, to keep the ram alive.

Any questions?

Sounds like you still have questions. For one, that is all Linus would have been able to do anyways, the RDRAND instruction isn't privledged.

You'd hope that whatever userspace program, be it openssl etc, would be smart about its usage of the RDRAND instruction. It would certainly need to be, as the RDRAND instruction doesn't exist on every CPU, certainly not a lot of older ones. Most any cryptographic software worth its salt has methods of specify its PRNG source as well.

Random numbers aren't something that should be left to chance.

It's not as simple as just commenting out a few lines of code.

No, it's easier than that. You can simply pass nordrand to the kernel. It was the first thing I saw when I opened up
arch/x86/kernel/cpu/rdrand.c
__setup("nordrand", x86_rdrand_setup);

So there...don't like rdrand, don't use it.

From Documentation/kernel-parameters.txt

                nordrand [X86] Disable the direct use of the RDRAND
                                                instruction even if it is supported by the
                                                processor. RDRAND is still available to user
                                                space applications.