Most things will use OpenSSL. This is because OpenSSL is the lowest
level anyone should be going to for this. Anyone who re-implements an
encryption algorithm is doing the bad thing.
From whom are you trying to hide the credit cards, though? From
anyone who has full access to the machine? From someone who might get
a database dump? What about getting your application code as well?
Do you want one-way encryption and want to only decrypt if the data is
removed from the machine?
Encryption comes in two flavors: shared key and private key. The
shared key version uses the same key to encrypt as it does to decrypt,
while public key uses a different (but related) key for each step.
If you are wanting to store the credit card so that your application
can later decrypt it, anyone who gets that key can also decrypt
anything you are trying to hide. Thus, if you host your application
and someone gets the source code for your application and the database
dump, game over. If you are not worried about this, you should be.
If on the other hand you are only decrypting in “emergency cases” such
as when someone contests a charge and you need their actual number,
you can choose public key. The server encrypts the data, Base64
encodes it, and stores it in the database. If you need to get it, you
get that encrypted value and copy it to your desktop, where you run
the Ruby script to decrypt it. This is probably the most secure you
can get without adding in hardware. You just never, ever store your
private (decrypt) key on the web server.
Often I use a very, very simplistic “encryption” just to mask the
contents of data, such that my debugging won’t reveal it. For
example, I’ve stored passwords in the clear for a whole set of
automated API scripts, none of which needed to be 100% secure, but
used ROT-13. Why? So “select * from…” did not reveal the contents.
So, it comes down to, who are you trying to hide the CC numbers from,
and what is the threat model?
–Michael