AES and Credit card number encryption

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Tobiah

    #1

    AES and Credit card number encryption

    I browsed this subject and thought I might use the
    'AES' cypher scheme to do this. Would this be
    a good choice?

    I came across a "Python Cryptography Toolkit"



    which has a nice AES implementation, but in
    the example, a simple string is passed as the
    key:

    obj=AES.new('ab cdefgh', AES.ECB)

    So my real question is, how do I go about
    generating the best key. Isn't the length
    supposed to be a 2^n bits, and soforth?

    Thanks,

    Tobiah

    --
    Posted via a free Usenet account from http://www.teranews.com

  • Paul Rubin

    #2
    Re: AES and Credit card number encryption

    Tobiah <toby@tobiah.or gwrites:
    I browsed this subject and thought I might use the 'AES' cypher
    scheme to do this. Would this be a good choice?
    There's more to it than that, but yes, AES is a good underlying
    algorithm.
    So my real question is, how do I go about generating the best key.
    Isn't the length supposed to be a 2^n bits, and soforth?
    AES key length is your choice of 128, 192, or 256 bits. In practice
    128 bits (16 bytes) is fine and is what most people use. You should
    use 16 completely random bytes. Get these by reading them from
    os.urandom(16), which is provided for basically this purpose.

    Comment

    • Tobiah

      #3
      Re: AES and Credit card number encryption

      Paul Rubin wrote:
      Tobiah <toby@tobiah.or gwrites:
      >I browsed this subject and thought I might use the 'AES' cypher
      >scheme to do this. Would this be a good choice?
      >
      There's more to it than that, but yes, AES is a good underlying
      algorithm.
      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. You see we have to write
      the number often, but almost always only have to access (read)
      a masked number (4232********34 35).

      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.

      --
      Posted via a free Usenet account from http://www.teranews.com

      Comment

      • Paul Rubin

        #4
        Re: AES and Credit card number encryption

        Tobiah <toby@tobiah.or gwrites:
        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.



        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:



        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.

        Comment

        Working...