AES and Credit card number encryption

[Paul Rubin]

Tobiah <toby at tobiah.org> writes:
> Looking at the problem further, I am getting the idea that
> PGP, or GPG (Asymetric encryption) would be better, because
> then all of the software that has to *write* CC numbers, would
> not have to access the 'secret' key.

Yes.

> PGP sounds great, but it seems like a huge subject to cover
> in a day or two.  Is there a nice module for python that would
> let me do the most usual operations easily?  I just want to make
> a key, hide it, and the use the public key to encrypt all future
> and past credit card numbers.

I think I did hear of a GPG module.  You can also call GPG as an
external library.  There are also modules around that do public-key
operations directly, or some like M2Crypto that use OpenSSL for public
key operations.

I wrote something a while back for applications pretty similar to
yours, but never released it.  I should clean it up sometime.  At the
moment I wouldn't consider it well-tested enough for deployment in
real applications, and also it currently doesn't support AES because
it was written to avoid using C extensions, so it used a nonstandard
pure-Python cipher.

  http://www.nightsong.com/phr/crypto/crypto.txt

If you want to just encrypt stuff in pure Python and you don't mind
using a nonstandard (but reasonably secure, at least compared with the
old rotor module it was written to replace), it's here:

  http://www.nightsong.com/phr/crypto/p3.py

Note that you get a ciphertext considerably longer than the plaintext.
This is unavoidable for various security reasons and a proper AES
setup (or a call to GPG) will be the same way.