Home Original page

New Python block cipher API, comments wanted

Paul Rubin phr-n2003b at NOSPAMnightsong.com
Wed Jan 29 03:01:39 EST 2003 
Erik Max Francis <max at alcyone.com> writes:
> PEPs are Python Enhancement Proposals; they are intended to justify
> (and explain) an enhancement to the developer community, and namely
> to the folk(s) that decide what goes into each release of Python.

Yes, however, in the case of library modules, history shows that
whatever justification takes place is almost always done by means
other than PEPs.  

> > Also, as I mentioned to David, there's already been a PEP for block
> > ciphers (PEP 272) and it wasn't all that helpful.  I don't think
> > anyone has ever implemented what it specifies.  Doing another one
> > doesn't sound terribly worthwhile.  It's just going around in circles.
> 
> Why is it going around circles to revise the PEP that concerns this very
> subject, fulfilling the very role for which PEPs were introduced? 
> Revise the relevant PEP and make it will be accepted into the next
> release.

PEP 272 is about the Python interface to what in the new scheme would
be considered the codebook layer.  In the new scheme, there's less
need for something like PEP 272, because the Python interface to the
codebook is so much simpler than PEP 272 that it's obvious how to do
it.  The stuff that people care about is the user-visible layer, which
is outside of the traditional realm of PEPs.

Note that I don't have a serious problem with the idea of revising PEP
272.  I just don't want it to add a needless delay to releasing actual
code.  The author of PEP 272 has told me he's ok with the new
interface.  Also, the revision would probably mostly deal with
standardizing the C interface to the codebook layer, not the Python
interface.  So the stuff in a revised PEP 272 would just be about how
the internals of codebook modules should work, which only codebook
module implementers would care about.

Be aware too that there's unlikely to be hundreds of these modules.
There will be the two important ones (DES and AES) at first, and a
couple less important ones might conceivably get added later.

> Why does this have to go _in_ Python, anyway?  Why not just release it
> as separate module?

To make applications that use the module more widely deployable.  See
my response to David for further explanation.  

What is the nature of your concern with this subject, anyway?  Do you
intend to use the crypto library, if it's released?  If yes, and if
you have technical concerns about it, why not just state them now
instead of going off on this tangent?
More information about the Python-list mailing list