[PYTHON-CRYPTO] Requirements

[PC Drew]

--On Monday, February 12, 2001 7:02 PM +0100 Michael Ströder <michael at STROEDER.COM> wrote:

> * It has to be possible to register implementation modules by system
> configuration to enable an application to use an algorithm or
> protocol without knowing in advance which implementation modules are
> present. The system's administrator specifies the order of the
> registered implementation modules during install time.
>

I'm not sure how I feel about this.  I think this could be really useful, but also really complex.  The question then becomes, is it worth the complexity?  Either way, I don't think we should focus on that right now. I think we should start building an API and then add on this feature.

> * The application has to be able to choose a specific implementation
> module at run-time by explicitly specifying an implementation's
> name.
>

correct.

> * An application which only needs a specific algorithm or protocol
> should not have to import a big multi-purpose library.
>

great idea.

> * The above implies the need for unique identifiers for algorithms,
> protocols and vendors throughout the whole class API.
>

correct.

> * It has to be possible to define all parameters for algorithms or
> protocols through the API. Reasonable defaults should be used
> whereever possible.
>

this is a must.  the user should be able to do anything or nothing.

> * At least in debug mode an exception should be raised if the
> application passes wrong types of parameters to class methods of the
> API.
>

I think this should be done all of the time, not just in debug mode.  I'm curious, why do you say "at least in debug mode"?  Is there an example that 
you have in mind where you wouldn't want to know this information?

> * Same API for same type of component (e.g. a key store should be
> always looking the same to the application)

correct.

Here are some more goals that I would like to see come out of this:

* Build a cryptographically strong PRNG that can be freely distributed with 
the Python package, that also works with our crypto package.

* Handle key exchanges and have a key "ring" that is available to all of the algorithms.  The key "ring" would be a seperate module that checks to make sure file permissions are "secure" and reads and writes keys.

* (this elaborates on one of the goals from above) Let the user access all points of the library.  If they want to deal directly with the algorithm, let them.  If they want to encrypt an email using PGP, let them (i.e. handle the key management and the encryption, etc).

* Have as many algorithms as possible, maybe starting off with pure python implementations and moving to C/C++ in due time.  The reason that I think we should go from Python -> C/C++ as opposed to the other way is because by 
using Python to first implement the algorithm, we can a) get it up and running more quickly and on more platforms and b) because it provides a good reference implementation, rather than a really fast implementation that would come later.  Remember, do it right first...then make it really fast.

* Provide an easy installation.  Ever tried installing GNOME or X from scratch?  You have to get about 500,000 packages and install them all.  No fun.  I want to provide as much as possible (if not everything that's needed) in one file.  When someone downloads this, they should "configure; make; make install" and it a) works every time and b) installs everything that's needed.  If that means including other peoples packages with ours...so be it.  I haven't installed the UNIX version of the PyXML package, but the windows install is great.  That's exacly what I think is necessary.

* Keep updated documentation on the web (hopefully python.org) along with links to more detailed information about each of the algorithms.

* Release every 6 months.  This should be bug fixes, new algorithms, new features, it doesn't matter.  Release good and release often.

* Audit other people's code.  Let's take a lesson from the OpenBSD guys and 
do things right.

What are everyone's thoughts on these new goals?

--
PC Drew

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