[PYTHON-CRYPTO] aes library

[Paul Rubin]

    [Brian Mongeau]
    Yes, I'm here and I've been loosely following the recent thread
    about an AES API. I'm sorry to say that I have to also operate a
    business and as such cannot devote as much time as I'd like to
    improving my crypto lib.

Ok, that's understandable--I'm glad you're here regardless.

    I haven't yet participated in the conversation because I have my
    doubts about strong encryption ever being included in the standard
    library.

I'm fairly optimistic about getting an AES-based encryption module
accepted, since they already have that silly rotor module.  I worry
more about getting a platform-dependent CPRNG accepted, and we need both.

    I also doubt that a single API could ever please everyone.  As for
    my AES API, I initially designed it according to the policy of
    least surprise for the un-initiated, so I recognize that its
    current incarnation probably isn't as flexible as it ought to be
    for the power-user and as such I am willing to change it.

Fair enough.  If you're ok with it being the basis of a more general
purpose AES module, I guess we can start hacking it.

    ECC ( still being developped, 80% complete )

Do you think that implementation is better (faster?) than a
straightforward implementation in Python using Python long ints or
gmpy, in characteristic p, maybe with projective coordinates?

    As stated many times, the primary goal of my kit is to provide a
    smaller, easier, faster and more secure replacement for SSL
    network connections.

I just looked at the cryptsock.py code and immediately notice:

  1) it uses cPickle to deserialize messages, which has a security
     hole (see current pickle docs) if the peer is hostile.

  2) It appears to do an ECC signature on every message--why do that,
     if there's a shared secret key for the session?  Just put a
     checksum underneath the secret-key encryption.

However, this gets off the topic of AES.