We give our clients a very simple recommendation when it comes to encrypting things:
* If you're encrypting data in motion, rely on SSL.
* If you're encrypting data at rest, rely on PGP/GPG.
There are plenty of libraries that will GPG a blob for you, and you can assume GPG got all the details right. That would have been the right call here (as opposed to figuring out CBC and --- importantly, for someone who is still fetishizing "salts" in 2009 --- how to safely set an IV).
As an obvious counter example, asymmetric encryption (gpg,et. al) is very slow. Which means that if I need to encrypt a lot of data at rest it sometimes makes sense to use a symmetric cipher.
Security (even just the subdomain of encryption) isn't that easy - there is no one-size-fits all solution.
Like I posted upthread, there's a laundry list of things that program is going to give you besides picking a better algorithm than "Triple DES" and a better block cipher mode. But listing them is just begging for a bunch of people to propose wack-ass alternative solutions that other people will feel obliged to waste time knocking down.
* you know specifically why SSL/GPG falls short of your requirements
* you realize that algorithms are only a single part of crypto system design
* you know the exact security ramifications of the details (not just "ecb is bad")
* the encryption capabilities are the critical aspect of your whole system (like freenet)
* you accept that your implementation will be broken (at least) several times
But indeed if you know these things, you know that "use SSL/GPG" is good canonical advice.
There are a few algorithms to choose from.