Block cipher API again

Paul Rubin <[email protected]>
Newsgroups gmane.comp.python.cryptography
Message-ID <[email protected]>
Hi, a while back we got in a long discussion about spec'ing and
implementing block cipher API.  The last thing I remember was
proposing that the block cipher implementation should only implement
one mode, namely a codebook lookup; all other operations should be
done by a generic module that does codebook operations.

Anyway I've written a prototype of what I meant by that.  It's at:

    http://www.nightsong.com/phr/crypto/blockcipher.tgz

Included are:

  1. blockcipher.py: the prototype block cipher API.  It implements ECB,
  CTR, and CBC modes, though it needs more features.  OFB and CFB are
  currently unimplemented, though I should do those too.  This is what
  I mean by a generic module.

  2. lr64.py and lr128.py: two sample block cipher implementations, a
  64-bit one and a 128-bit one.  Both are straightforward codings of
  the Luby-Rackoff algorithm calling the built-in SHA module.

  3. secrand.py: secure random number generator for *nix, that works by
  reading random bytes from /dev/urandom.  It can generate random byte
  strings, or random integers of arbitrary size (useful for public key
  methods). I use this module all the time for all kinds of stuff.

  4. test.py: a test harness for the above, just run it to self-test
  the other stuff.

General plan:

1. Reach some consensus about what the blockcipher.py API should do,
including a working implementation.  This may take several passes
and some discussion.

2. Reimplement the agreed-on API in C.  This should be straightforward
and I can do it.

3. Write Python-callable C implementations of AES, DES/3DES,
and other ciphers as desired, that implement the codebook interface
needed by the blockcipher API.  Again straightforward, it just means
putting Python wrappers around existing C ciphers.  I can do this too.

4. Write a C implementation of secrand.py that works in Windows, that
gets randomness from the Microsoft CAPI CryptGenRandom call.  This
will have to be done by someone with Windows development tools (I have
none) but I can provide some assistance/advice if needed.  The *nix
implementation should also be tested in Solaris, MacOS, etc.

5. Submit all of the above to the Python maintainers for hopeful
inclusion in 2.3.  This may have to happen in the next few weeks.

Comments are solicited.  And are we up for this?

Paul
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.