Having done this a few times, you should think about other stuff in addition to the encryption (tho that's core). I suggest going with GPG it's relatively easy to use and the GNU people have some very good documentation

There are a few other things you should worry about:

• storage protection - if it's in a file, is the filesystem secure enough? In a database? Is the database locked down properly?
• changeability - can the user change the CC in the future?
• viewability - do you want to show the user the CC number again? If so, as the full number or masked (XXXX-XXXX-XXXX-1234)?

What I've done in the past is store the CC numbers in a fairly secure database. The schema would have both an "encrypted" field and a "plaintext" field. When the user enters a number, it's stored in the plaintext field. Then a cron kicks off every X number of minutes to do the encryption. If encryption succeeds (it always has), the plaintext field is masked.

This gives me control over the encryption and simplifies it - I only have to worry about two keys - the user that encrypts and the user that decrypts. Trying to control a key for each user would be unwieldy for me (but may be fine for you). Given that everything else is fairly secure (till the next bug report), I have a layer of security at the firewall, a layer at the database, and a layer with encryption.

If the first two layers fail, I may loose X minutes of clear text CC numbers but I gain a lot in performance. By showing just the masked CC, I can stay in http (vice https) and there is no need to decrypt.

Some PHBs may crow about those X minutes but I always counter with the restaurant question - Did you give your CC to some unknown waiter who wandered off with it for 15 minutes?

-derby

update: I just re-read your question and I don't think you want to use symmetric cryptography at all. There would be no easy way to obfuscate the encryption key in your script. Asymetric (public key) crypto is definetly the way you want to go. And you want to have two keyrings. One for the front-end webserver and one for the back-end reporter. The front-end would encrypt with the back-end's public key, that way if your front-end user is compromised, the encrypted data still has a layer of protection since the front-end keyring cannot decrypt. Definetly read the documentation for GnuPG.

another update: Sorry for not being clear GPG (the one actually named GPG) is just a thin wrapper on top of the Gnu Privacy Guard. There are several public key perl modules - I found GPG and the Gnu Privacy Guard the easiest to get started with.