[PYTHON-CRYPTO] Comments

[PC Drew]

Sorry, I've been out of the loop for a while and just got caught up on a
500 messages from this new list :)

>From the looks of the last set of emails, I'm starting to see things that I
don't like.  Here are my thoughts:

1.  Start from the bottom and work our way up.  Meaning start with the
design of how we want to implement hashes (for instance).  Well, they all
need to have this, that, and the other functionality.  Okay, not that we've
designed and encapsulated each category of encryption, let's move up a
level.  How do we want to access these functions for consumer use?  Well,
they can access the module directly (i.e. import hashes.MD5) or maybe it'd
be cool to write a "find" utility to find the best MD5 implementation.  The
point is that we want to give the user as _much_ flexibility as
possible...first, design a good base interface, _then_ design a really cool
"find" module.  That should _not_ be the main focus at this stage.  Then,
once we've done this stage, then maybe an abstraction layer would be good.
Once that's done, let's try to get some of this into the python distro,
then, let's try and change some other modules to use ours (i.e. change the
random module so that it uses our cryptographically strong RNG).  That's
the route I see.

2.  There was talk about how to handle different implementations of an
alogrithm (i.e. MD5 in pure python, c, c++, assembly, etc).  I think this
is  _fundamental_ for this library.  Again, we want to give the end user as
_many_ options as possible.  If portability is their main focus, not speed,
let them choose the pure python version.  If they want speed and won't put
the software on anything but an i386 box, let them choose the assembly one
if they want to.  The key is finding a way for each implementation to
co-exist with each other...what if we defined a "implemenation" variable
for each module...one that stores "assembly" or "python" or "java", etc?
Or, since we'll be controlling the implementations that get included with
our package, why not just do a package structure: "hashes.MD5.python.imp1",
then if another MD5 in python module comes around, and we want to include
both, then call it "hashes.MD5.python.imp2".

3. For all those who are interested in actually having formal documents
describing the "new" (whatever comes out of these discussions) crypto
standard, can we first discuss high level goals and then go from there?  I
think that would be more constructive at first than everyone giving their
$0.02 about whether or not they want a find function.

4.  All in all, I'm really happy with the discussions that have taken place
in the last month or so...it looks like we are pretty much in agreement
about these things and I think that we can do some really great stuff if we
get some sort of organization.

--
PC Drew

  Be nice or I'll replace you with a very
  small shell script.