I agree. This is a discussion I've been meaning to start. But too many things to do, too little time

While the current encryption scheme in Ubercart is better than storing the card numbers in plaintext, the fact that it also stores the key (used to both encrypt and decrypt these number) on the web server means only that there is one more step needed to steal your card numbers - it doesn't add any real protection. If your web server can be compromised to gain access to your DB, it's likely that the key can be obtained at the same time. Regardless of the strength of the encryption method, the credit card data is only as safe as the key (not very!). IMNSHO, no one should be storing these numbers in their DB. But if they insist, the current method of protecting the numbers is not adequate.

(and, BTW, after reviewing the encryption scheme used by Ubercart, I have to say it's really quite weak. As in, I'm no expert but I could crack your key before I had my morning coffee while I'm waiting for my toast to pop. Details here http://www.ubercart.org/comment/14122/Re-CC-encryption-Bazaar-needs-test...)

An asymmetric (public-key) encryption goes a long way towards addressing these issues: The fact that the private (decryption) key would not be stored on the web server means that if your web host or DB were compromised, the encrypted numbers would still be useless.

Moreover, RSA/PGP/etc. are really incomparably stronger than the current scheme, and with a reasonable length key they can't be broken. (RSA can be broken with sufficient time and computing power, but by choosing the key length appropriately it can be made as secure as desired. PGP, on the other hand, has not been shown vulnerable to an attack of this nature - it really is pretty good )

Storing the private key locally also makes it a little harder to use - all that cut-and-paste - and you still have to worry about compromising the private key, but at least all the eggs aren't in the same basket. Perhaps a little JavaScript can be inserted to run on the client side which prompts the user for the private key then automatically decrypts any displayed card numbers on the page. That would address ease of use without sending the key across the wire.

Possible drawbacks to using these encryption methods are the availability of open source (GPL) implementations in PHP. I haven't looked into this, but it occurs to me that Drupal requires a number of external services to be available, and these don't have to be PHP, just callable from PHP. A DB server, for example... I would think that a GPL encryption library, even if it's not PHP, doesn't contradict the spirit of Drupal.

I look forward to trying out your contribution. May I suggest that you code it not as described in your post above, but as a drop-in replacement for the class uc_encryption_class found in uc_store.module. That way your code can be used with minimal disruption to core. (It would be interesting if core could accommodate different encryption methods through the use of a hook...)