[PYTHON-CRYPTO] Near-term projects for pycrypto

[Eric Johnson]

Sorry for the lateness of this reply (the server kept bouncing my submission)
but I don't think we have resolved this issue yet.


On Wed, Nov 21, 2001 at 05:52:38PM -0000, Paul Rubin wrote:
> 6) The above is from the philosophical standpoint that Pycrypt is
> mainly supposed to give app writers a way to put crypto into their
> applications without being crypto experts.  The alternate view it's
> more intended as a toolkit for experts.  Either view is ok with me,
> but the designers should make a clear decision about what the goals
> are, rather than muddling around between various possible goals.
>

I agree with this and think that we need to define what the goals of Pycrypt
are.

My personal requirements are to have a low level cryptographic library
which is easily extendible to use new algorithms and which can be used
to generate test data for
        * debugging and testing assembler implementations
        * statistical purposes (eg for DPA type attacks)
        * educational and experimental purposes

I would prefer to have a pure Python implementation for ease of modification.

I realise that these are esoteric requirements but I would like to think that
we could come up with a framework that would meet these and other peoples'
requirements.

Whilst, I think one goal should be to allow crypto to be used in Python
apps by non-experts is desireable, we should not handicap the system by
reducing the flexibility and prohibiting certain algorithms or modes of
operation.
Doing this will just give false confidence to novices -- most crypto failures
are at the system level rather than weak algorithms.

The following are on my wish-list for PyCrypt

1) It must use distutils for distribution purposes

2) It must have a pure Python implmentation with optional C extensions for
   those who need the performance

3) It should have a high-level API for novices and a low-level API for
   more sophisticated users.

4) It should be possible to select the algorithms and modes of operation
   using factory methods (so that it is as simple as possible to replace
   an algorithm or change the mode of operation)

5) It should be easy to implement a new mode of operation or algorithm
   and have it fit naturally into the framework - this should be the
   case for pure Python implementations and for C extensions.
   For example, if we do use openssl then it should still be possible
   for me to implement a C extension without having to modify openssl
   or wait for openssl to support this algorithm.


I think that we should concentrate on symmetric algorithms to start with.
The framework should be much simpler and less controversial than public
key.
Further down the road it would be nice to add some features that are not
so common such as secret sharing or generating domain parameters for
Elliptic Curve systems.


Eric Johnson