The point of this is you shouldn't even be using algorithms directly. If you need to touch crypto at all you need to learn about it, and the more you learn about it the more you'll realise just how damned hard it is.
Absolutely use common programs like GPG and common libraries like OpenSSL. In fact don't use anything else, and don't even think about implementing this stuff yourself.
I agree some sort of authoritative set of info would be good. Very hard to do though.
- from Kurt Vonnegut's novel Cat's Cradle
- Albert Einstein
- Abraham Lincoln
http://www.cafepress.co.uk/cp/customize/product2.aspx?from=C...
Also I'm pretty sure that's Diablo Cody's quote, not Einstein's.
Take OpenSSL for example... it's almost easier to learn the crypto than to figure out the API. Here's a good one: an SSL read/write operation can fail with more than one error, and if you don't clear or loop through all the errors then the next operation will fail because of the previous errors -- even if it succeeded. Or just try getting it to work with non-blocking sockets, you finally believe it is working and surprise it fails only once the network gets saturated. Or hours later when it renegotiates the crypto.
And you still have to know all the crypt terms to use it. What's a PEM? A BIO? PKCS? DHparams? What's "ASCII armor"? X509? Did SSL_library_init() add weak algorithms? Why do I have to know this just to create a secure connection?
Most of blame for crypto problems belongs to the libraries not the developers using them.
Instead, use NACL or Keyczar. Those are high-level interfaces designed to help generalist developers not make mistakes.