[PYTHON-CRYPTO] PEP 272 version 2

[Paul Rubin]

I have a meeting in a few minutes but will send out a short reply
now and add some more later.

Alex said

  I consider hardcoding one cipher algorithm into Python standard library a
  Wrong Thing.

but I don't think there's any suggestion of "hardcoding one cipher
algorithm into the Python standard library".  I'm not even sure what
"hardcoded" means here.  I have nothing against more block ciphers
being added, if applications need them.  That's just like there are
already multiple hash functions (MD5, SHA).  If there's a need to add
HAVAL or TIGER, they can be added without any fuss.  Yet there's no
PEP for hash function API's and there doesn't need to be one.

    [Andrew]
    Note, however, that this PEP is of type 'informational', and an
    informational PEP carries as much weight as an informational RFC; that
    is, none whatsoever.  Implementors *can* do what they like, and are
    free to ignore the PEP if they don't like it or if it's unsuitable for
    their application.  (At least that's what I've always thought
    'informational' meant, though PEP 1 doesn't actually make that
    explicit.  I'll talk to Barry Warsaw about clarifying this.)

This is confusing--if the PEP has no weight, why have it at all?
"Implementers can do what they like" is fine for people writing their
own apps, but we're talking about a submission to the standard library
which we're proposing be distributed to every Python user.  If the PEP
has any meaning, it's for that situation.  When our AES module doesn't
follow the PEP chapter and verse--and it won't-- Guido (or whoever) is
going to look at the submission and say "Why doesn't it follow the
PEP?  Please revise it til it does."  The possible resolutions are:

  1) Make the library follow the PEP--bad for technical reasons described
     earlier.  It will be pretty close, but some details will be
     different, and I'd thought we'd agreed there were some features
     we weren't going to bother with.
  2) Make the PEP follow the library--maybe better, but seems kind of
     pointless and constraining.
  3) End up not getting the module accepted for the library, and stay
     stuck in the bad old days--an outcome to be avoided.
  4) Eliminate the PEP and submit the library without the PEP, as worked
     perfectly well for hash functions.  Why fix what isn't broken?
     So IMO, this is the best route to take.

I think writing a PEP for something as low-level as block ciphers is
excessively concerned with process.  I'd rather concentrate on getting
code running.

    For example, the other informational PEPs are the Database API
    specifications, and there are database modules that don't follow
    them.

The database API PEP is more useful than a block cipher PEP because
there's a real need for applications to be easily switchable between
different databases, and the interface to database is far more
complicated than the the interface to block ciphers.

I do like the idea of a cryptography PEP for Python, but IMO it should
be at a much higher architectural level than PEP 272, i.e. it should
be more along the lines of JCA.  I'd be happy to help write such a PEP
after the AES module is done.