New Python block cipher API, comments wanted

[Paul Rubin]

Chad Netzer <cnetzer at mail.arc.nasa.gov> writes:
>    Pardon me for asking Paul, but why the rush?

If not now, when?  If not me, who?  ;-)

Seriously, right now is early enough in the 2.3 release cycle to
submit a new library.  The idea is come up with something to submit
while it's STILL early enough.  And it's desirable to get some
reasonable crypto out there soon because there are applications
waiting to use it.

>    'Haste' and 'Cryptography toolkit implementation' are two phrases
>    that do not seem like they should go together.

This isn't really a "toolkit" (it doesn't do any complicated
protocols).  It's just a Python interface to modes of operation that
have been tried and true since NIST's predecessor first published DES
as a US federal standard in the 1970's.  It's not rocket science.  It
just Pythonizes what's already been done in numerous other languages
and it's hard to go too far wrong with it.

There are some ideas circulating for a higher level Python crypto
architecture and toolkit (sort of like the JCA) that should go through
the PEP process, but that's not what this is intended to be.  This is
low level.

>    I appreciate your enthusiasm, but I can't help but think, if you
>    are aiming to get this into the standard python distribution, that
>    you should be shooting for the NEXT version of python (say 2.4),
>    to let your interface and implementation have time to settle out.

Letting stuff settle out is precisely the purpose of the alpha and
beta release series, which is where we are in 2.3 right now.  That's
why I want to make the next alpha.  Also, this started several months
back, before the 2.3 cycle really began, though I ended up letting it
slide for a while.

I think there's enough time to get this right for 2.3, so I'm aiming
for 2.3 and trying to make it.  If it turns out not to make it in
time, that's ok, but I'd hope to aim for 2.3.1 next, rather than wait
for 2.4.

>    PEP 2 would seem to indicate that you will need to build 
>    some consensus to actually get your module accepted.
>
>    You seem to be responding (at least in part) to PEP 272, which has
>    an alternate design for a cryptography module (or modules).
>    Wouldn't it be best to respond to that PEP, and update it, or
>    perhaps put forth another PEP for people to consider?

If it helps, I'll assure you that I haven't been doing this in a
vacuum and that I didn't think all this up the day before yesterday.
The block cipher API topic has been discussed endlessly on the Python
crypto list (you should join that list if you're interested in the
subject).  Consensus there (including from the author of PEP 272)
seems to be that the current proposal is ok.  So you can think of this
scheme as coming from the python-crypto list and not just from me.
The purpose of posting to c.l.py was to get a little wider exposure
before freezing the API, but this was supposed to be the end of the
comment process, not the beginning.

Anyway, the mailing list proposals and discussions slipped into going
around in circles long ago, as such things do.  So we're at the point
of needing something concrete to test out and say yes or no to.  If
you have concrete suggestions for changes or improvements to the
module, please speak up with them.

>    Wouldn't it be best to respond to that PEP, and update it, or
>    perhaps put forth another PEP for people to consider?

Another PEP hasn't really felt necessary, given the discussion we've
already had on the crypto list.  Notice that PEP 272 is about what
functions codebook modules have to implement.  The current scheme, if
written as a PEP for codebook implementers, would be much simpler than
PEP 272 because the current codebook modules only have to implement
ECB mode.  So a new PEP would just be PEP 272 with the non-ECB modes
removed, pretty much.  Does anyone seriously think that's necessary?

Actually, a PEP may be appropriate for standardizing a C interface to
codebook modules, but right now it's too early to worry about that.

>    Also, there are other python cryptography toolkits, why should
>    yours be included and not theirs (especially when they've been
>    around longer, and probably have more users).  I'd hate to see
>    multiple toolkits put in just because everyone was too hasty for
>    the API to settle down and show its worth.

This isn't a "toolkit" (it doesn't do any complicated protocols like
SSL), but rather it's just an interface to some fairly low level
operations that are already very standard.  It seems easier to get
something like this accepted into Python than a fancier toolkit that
does more.  And getting these basic modes into the standard library
will allow writing toolkits in pure Python that implement most
standard protocols with reasonable performance.

>    In the mean time, I'd say get a place where people can publicly
>    discuss your module (I'll subscribe to python crypto mailing
>    list), and track revisions.  Also, get the test vectors included
>    and working, so you can make changes without fear of unknowingly
>    breaking the cipher.  And when you distribute a tar file, make
>    sure it untars into a subdirectory, not the directory of the tar
>    file (which is annoying, especially if the number of files grows large)

OK, thanks.  The Python crypto list is the appropriate discussion
forum.  You might want to look at the archives when you join.  Good
point about the tar file.

>    In any case, I haven't fooled around w/ cryptography since my Java days 
>    (when I did my graduate coursework in it), and now that there are some 
>    good Python alternatives, I might get back into it.  But you need to 
>    allow people time to use your module before you can get reasonable 
>    feedback on it (IMO).

Yes, that's precisely the goal here, in asking people to download it
and play with it.

Thanks

--Paul