Smoking (Cloud) Crack

Making waves in the infosec blogosphere today: Cracking a PGP-protected ZIP file using Amazon's EC2 cloud computing infrastructure. There's some interesting data presented, especially when extrapolating the cost involved with breaking the encryption. There are a number of flaws in the write-up, though. I'll take it to task here, then cover some of the important and extremely valid points that the write-up did make.

This was a brute force password attack

If you happen to intercept PGP communication between two people, there's no password in the world that can decrypt it. The password (or passphrase) only unlocks the secret key, which is actually needed to decrypt the communication. If you don't have the secret key, your options for recovering the encrypted content are mathematically tantamount to nil. If you do have someone's secret key file, that person did something very wrong and stupid. The proper thing for that person to do when there's reason to believe their secret key is compromised: revoke the key, and tell everyone that the key has been compromised! I cover some of this in my GPG Key Management & Signing Article. Some Cloud Crack™ was being smoked by someone, as the crackers had access to the secret key, which shouldn't ever happen.

It doesn't always cost millions of dollars for CPU cycles.

Ages ago, my friend Bob had distributed.net agents running on 90% of the lab computers at the college he attended. These were all fairly new computers, too. Have physical access to 100 computers? You can probably spawn 100 instances of EDPR. For free. As in free beer. Okay, free beer plus the cost of the EDPR entitlements.

Plain old CPU cycles are so '90s. These days, we have the ability to harness compute power of FPGAs, and thanks to things like the CUDA architecture, Graphics Processing Units (GPUs) as well. These technologies take traditional CPU cycle density and cost paradigms and turn them inside out. It doesn't come cheap, but it's surprisingly affordable, more efficient, and denser than building racks of x86 machines. The author spoke of a corporate espionage scenario, with budgets of around $1M to compromise a competitor's data. $1M would go a very long way with FPGA or CUDA technology.

Finally, there's the black-hat side. Botnet zombies are cheap. Spammers, scammers, and malware tycoons know this. If you have some skills, free time and lack a moral compass, you can roll your own botnet or hijack someone else's botnet zombies for free. Again, as in free beer. Don't think it happens? Don't kid yourself.

Brute Forcing is real

While brute force doesn't work against PGP in a perfect world, it does work almost anywhere a password is involved, and the numbers don't lie. An attack like this against an encrypted TrueCrypt volume, for example, would be bone-chilling if it succeeded. Normal "protected" zip files, documents, and accounts are vulnerable, and there are multiple tools to brute force almost any kind of password.

Longer is better, for the most part

Long, simple passphrases win out over short, complex passwords when it comes to brute force. Still, if you use something that's easy to guess, like the first sentence of the book currently marked as your favorite on some social networking site, you might be in trouble. The ways you choose, guard, and use your passwords are parts of a very complex problem that not even the best in the industry can agree on a solution for. Good luck with that.

If all else fails, there's always rubber-hose cryptanalysis. Remember, you can't hide secrets from the future with math.

On cloud computing

It seems everyone is blaming a general failure of cloud computing for the massive data loss that hit Danger, Microsoft and T-Mobile over the weekend.

From what I've read, a failed storage upgrade occurred without a good, solid backup in place. That sounds a lot more like a failure in backup, planning and design than a failure of cloud computing to me. Had the storage folks at my office made the same mistakes, that's what would have been said -- right before the human resources folks came to "have a talk" with the team.

It just so happens that T-Mobile's sidekick phones rely on a lot of back-end storage, so there's the whole "cloud" element to things. I'm not familiar enough with the Danger platform to know how easy it is to back up your own data, but I'd hope it's possible.

I think it goes for any service where you've entrusted storage of your data to someone else: make sure you back it up yourself, if you think it's important. The difference with the Danger/T-Mo disaster, I think, is that it was a lot less obvious to end-users that the data wasn't all stored permanently on the phone. Clearly, "cloud computing" was collateral damage in the wake of a much more mundane failure. The fact that it was completely avoidable offers little comfort for those affected.

Shifting gears: Along comes this piece on how e-mail is becoming less and less relevant.
The thing that separates e-mail as we know it from other messaging platforms is the fact that e-mail is decentralized. Using information stored in DNS, all Internet-facing e-mail servers can properly send mail to the correct server for a given address. IRC is another decentralized communication protocol. The days of decentralized infrastructure are fading fast, though, being replaced by walled gardens that want your constant attention, and many of them requiring a separate account and password. These walled gardens are supposed to be "the new way" of communicating.

You can't easily backup everything you've received through Twitter or Facebook, and the people who communicate with you there have to have accounts. Sure, anyone can get an account. What about Google Wave? Very few of the people I REALLY want to collaborate with have an account. So, while I do see a lot of value in these services for certain things, I don't think that any of them are quite ready to fill the roll that e-mail currently provides. Chiefly: if I have a local e-mail client running on my system, I don't need to suckle at the teat of the Interwebs in order to rifle through my data. It's right there, on my computer. Web mail has indeed blurred the line, but the good web-mail providers still offer mechanisms to back-up your data or use an offline mail client such as Thunderbird.

OpenID somewhat fixes the need to have multiple accounts and passwords scattered all over the web, but shifting authentication "into the cloud" just means that each OpenID account we have will be more catastrophic if compromised. OpenID is tantamount to using the same username and password everywhere, and we know how well that works for security.

How do you backup your cloud data? Well, for starters, you can try a native-client RSS aggregator such as Liferea. One thing that "Cloud" is doing is making syndication possible through ubiquitous RSS feeds. Backups won't work perfectly on every site, for example: you won't actually download all of the photos from Flickr with RSS, you'll only get links to them. It will nicely archive text content, though. This is good for things such as blog posts, twitter conversations and the like.

PHP Editing In The Cloud

I ran across PHP Anywhere over the weekend. At first glance, it looks as feature-rich as the free version of PHP Designer, a Windows-only tool I use at work when I have to mess with PHP (which isn't too often)

There's just one question I have: who in their right mind would store the FTP password to their web site "in the cloud" like this? In fact, I don't even have FTP access ENABLED on my primary web server. I set up a test instance somewhere else to play with PHP Anywhere. I usually scp my files to their destination. Sadly, that's not an option for PHP Anywhere yet, but if it did, you'd still be storing credentials to modify your website...



I suppose if you are really in a crunch somewhere and lack your usual desktop IDE of choice (and for some reason can't get on the system to edit it locally), it makes for a neat toy.

That's all for today. I'm going to change my password on that FTP account now...