[PYTHON-CRYPTO] aes library

[Paul Rubin]

    [Bram]
    > I thought we weren't going to try to mix modes for a single key, i.e.
    > we'd have:
    >
    >    a = AES.ECB(key)
    >    a.encrypt(str)
    >    a.decrypt(str)

    That's the approach I gave before, I figured I'd float this other
    one as a possibility - I don't have a strong preference either
    way, although if you're going to do both CBC and ECB operations,
    for example, the approach I just gave avoids multiple key setupds.

I strongly prefer separate objects per mode.  Mixing modes probably
leads to security failures.

    >     a.streamout(n)    # same as a.encrypt('\0'*n)

    The above is almost identical to the methods I meant to post for counter
    objects, except that I didn't include a streamout (although I can see it's
    utility, I don't have a strong opinion about it).

I think it's useful, but don't like the name streamout, and wonder if
anyone can suggest an alternative.

    reusing iv's is such a bad idea that I think having set_iv and
    get_iv is inadvisable, since it doesn't have any performance
    benefit when you're not reusing iv's, and encourages very bad
    behavior.

The idea isn't to re-use iv's, but rather, to be able to encrypt a
single message in multiple pieces if for some reason you don't want
to keep the cipher object open between pieces.  Normally you wouldn't
use these.

    I don't like the direction call at all - encryption and decryption
    are two completely different operations, likely not using any
    shared code, and using direction='d' is vastly more obscure than
    calling the constructor of CBC_decrypter.

They'd share code.  A direction flag is how most other systems do it,
and no one has complained.  I don't see any big philosophical difference,
and fewer different constructors makes the implementation simpler,
so I'd rather stay with the direction flag.

    Is it currently possible to implement DSA in pure Python? I'd like
    the minimum base functions put into the standard libs which make
    basic strong crypto possible without resorting to C code.

The math part of DSA is easy to implement in Python, but DSA requires
secure random numbers.  So once again, the CPRNG is the obstacle, not
the algorithm.

Btw, is anyone here good at Windows C programming and have dev tools?

Also, is anyone here on Python-dev?  We should send them an email
asking what kind of module they'd accept.  I propose something along
these lines:

   1) We think the "Cryptographic Services" part of the library should
      include a good encryption algorithm to go along with MD5 and
      SHA.  The rotor module is of questionable security and should be
      deprecated.  So we'd like to submit a module that does
      encryption based on AES, for inclusion in future Python
      releases.

      It would have an easy-to-use interface like the rotor module,
      and also provide an API that allowed more fine-grained control
      of the algorithm (modes of operation, etc.) for users who want
      that.  This module would be written in portable C.

   2) We'd also like to submit a CPRNG module.  Secure random numbers
      are central to many security algorithms and protocols, and
      CPRNG's are included in most current OS instances.  The lack of
      a CPRNG is a serious deficiency in the Python library.

      Unfortunately, it's not possible to write a good CPRNG portably.
      So we'd like to submit a CPRNG module with platform-dependent
      code that calls the OS-provided CPRNG's for Linux/BSD (apparently
      including Mac OS 10) and for Windows.  This should cover most of
      the boxes currently running Python.

      For other platforms we may be able to supply a sort-of-useable
      portable CPRNG that uses thread racing, but it should be used
      only as a fallback measure.  (This is sort of like the portable
      implementation of java.security.secureRandom, and anyway not all
      platforms provide threads).  However, even if we can't support
      all platforms, we still urge shipping a CPRNG for those
      platforms that can support it.

   3) For interoperability with older systems, we'd like to also support
      DES/3DES (DES is the predecessor of AES).  However this is lower
      priority for us than #1 and #2.

   4) We'd like to know the opinion of the Python maintainers about
      this stuff: how big an issue is OS dependence for #3?  Should we
      make separate modules for AES, DES, and CPRNG, or combine them all
      into one?  Is it ok if the AES/DES modules have a number of modes
      and entry points that will interest only advanced users?