New Python block cipher API, comments wanted

Paul Rubin phr-n2003b at NOSPAMnightsong.com
Wed Jan 29 21:16:39 CET 2003


Chad Netzer <cnetzer at mail.arc.nasa.gov> writes:
> I realize your intentions are good, and I think the code and ideas show 
> promise, and as I said before, your enthusiasm is helping to get people 
> interested in your work.  But the way you floated the idea, at least in 
> this newsgroup, comes off as VERY presumptuous.

I apologize if it came across that way.  I didn't think I was
"floating an idea".  I thought I was posting news of something that's
been in the works in the python-crypto group and under discussion
with the Python maintainers for months, though inactive for a while.

> Frankly, that is all well and good, but when you talk about modules
> dealing with security and cryptography, there are many people who
> appreciate a MUCH more conservative attitude for adoption; they
> don't want to use security related code written by a hotshot in a
> few weeks.  They want testing, testing, TESTING, and more testing.

Keep in mind that we're not talking about a complex system like
OpenSSL or PGP, that has a lot of platform dependencies and a lot of
execution paths that need to be exercised.  It's just some Python
bindings for already-tested code that computes straightforward math
functions.  The interface is also nothing amazing.  It's just Python
language bindings for functions that have already been done for many
other languages.  As for testing, yes, as mentioned, the module won't
be submitted unless it passes NIST test vectors.  It will also have to
undergo some code review, plus exercised for possible memory leaks and
stuff like that.  Following that, there's at least one upcoming alpha
test followed by (I think) two beta tests.

As for whether this can get done satisfactorily in time for 2.3: I
don't know, but as I said before, the only way to find out is to make
the effort and see.  So that's the logical thing to do.

> Then they want to make sure they don't get boxed in and have to
> change later (they want it to work now and forever, with as few
> changes as possible.)

I don't think this is a big issue.  Again, we're not talking about an
elaborate grand architecture.  It's just Python language bindings to
do similar things to what's already been done many times in other
languages.  At worst, it will omit some features that some
applications turn out to need, and then there may be reason to later
add those features.  That happens with every type of software.  It's
not a big deal.




More information about the Python-list mailing list