[PYTHON-CRYPTO] Requirements

[Michael Ströder]

Dan Parisien wrote:
>
> On Tuesday 13 February 2001 22:21, you wrote:
> > > Especially with hardware crypto implementations. How would you propose a
> > > programmer use the find alg?
> >
> > Most folks would do:
> >         des=crypto.symmetric.factory(mechanism='3des')
> > which would let the local system find the "best" implementation.
> >
> > Some might have an ordered list of preferences:
> >         AES=crypto.symmetric.factory(mechanism='AES',
> > prefs='hardware:openssl:pycrypto')
> >
> > A high-security application, such as for a bank, might use
> >         rsa=crypto.asymmetric.factory(mechanism='RSA',
> > 'prefs=Fips140-1-Level4')
>
> Goodness. I see why you would want it, but I still oppose this type of
> system. It is in my opinion [of course it's in my opinion :) ] anti-pythonic.
> This type of registry should be at an OS level/programming language
> independant with python wrappers accessing it, not in the pyton crypto api :(

I do not see a problem. Yesterday evening I started on implementing
such a thing.

The module directory layout looks like this:

crypto
crypto/__init__.py
crypto/exception.py
crypto/registry.py
crypto/hash.py
crypto/cipher.py
crypto/factory.py
crypto/impl
crypto/impl/__init__.py
crypto/impl/M2Crypto/
crypto/impl/amkCrypto/
crypto/impl/Python/
crypto/impl/Python/hash.py

crypto/impl contains wrapper modules for current implementations or
new implementation modules in a flat name space.

The registry modules looks like this:

# Leave import statements untouched!
import crypto
from crypto.impl import *

# Edit this dictionary
registry = {

  # Hashes

  # MD5 implementations
  '(0 2 262 1 10 1 3 2)' : [
    Python.hash.MD5,
  ],

  # SHA1 implementations
  '(1 3 14 3 2 26)' : [
    Python.hash.SHA1,
  ],

  # Asymmetric ciphers

  # RSA implementations
  '(2 5 8 1 1)' : [
  ],

  # Key stores

} # registry

It's just a dictionary of lists of class names. The lists maintain
the preferred order. A factory function returns an instance of this
class. Very simple.

A few points:

- Anybody concerned of a system admin having to edit a Python
module? If this looks too scary we could write code generators for
the registry module later.

- Is anybody scared by OIDs at all? Do all required components
(algorithms, prng, key stores, protocols) have OIDs assigned?
(Likely not.)

Well, the dictionary also allows us to use aliases (second
dictionary for alias mapping) or assign new names for entities which
do not have an assigned OID. We could also register implementations
by opening a Python OID arc, etc.

Hopefully I will come up with a more or less complete tar.gz this
week-end.

Ciao, Michael.