Sorry about jumping into this thread so late. When it was first posted, the above link to the "GPL encryption class" was broken, so I couldn't evaluate the algorithm. Then I forgot about it until I saw a related post this morning (http://www.ubercart.org/forum/development/3591/ubercart_and_credit_card_...). I've now read up on it and I'm not real comfortable with what I see.

Bottom line: The current encryption method is extremely weak and should be replaced as soon as possible with strong public-key method.

(Ryan, I realize that this post sounds a little critical, but the criticism isn't aimed at you. Protection of credit card numbers is an important issue, and you've taken the time to address it in Ubercart, which is great. And as far as I can tell Ubercart handles the issue at least as well as any other open source e-Commerce solution. So please read the following as a condemnation of the algorthm, and not of you.)

Ubercart uses http://www.tonymarston.co.uk/php-mysql/encryption.html as the basis for its credit card encryption. That URL describes a keyed polyalphabetic substitution cipher, similar to the Vigenère cipher which was first created in the 16th century and was used frequently by the South during the American Civil War. (Interesting historical note: Charles Babbage was the first person to figure out how to break this cipher, sometime in the mid 1800's). These types of ciphers can be quickly cracked with a computer since a frequency analysis will determine the key length and a dictionary search or even simple combinatorics will yield the key. (Lengthening the key past 16 characters - the length of a credit card number - will not help). Likewise, if you have even one piece of plaintext to compare to the ciphertext (e.g. you place an order with a known credit card number), the key can be recovered almost trivially. Compounding this is the regularity of credit card numbers: The first digit is known, there are only 10 symbols (0-9) used in the number, and the checksum built into the number restricts the possible combinations. Also, the more encrypted credit cards numbers you have the easier it becomes to recover the key.

Frankly, given the availability of extremely strong open source encryption algorithms, there is IMO no good reason to use the current method. I think I understand why it was chosen - the Drupal GPL requirement and the availability of a PHP implementation - but these are poor criteria. The only thing that matters is, can the encryption method adequately protect the credit card numbers? For the current scheme, I have to say no.

That said, now that the encryption framework is in place, it's probably easy to plug in a new algorithm. I wish I had time to tackle this myself, but TCS, in his post referenced above, seems to have a solution almost ready to go - I think this should be examined and folded into core right away!