[PYTHON-CRYPTO] block cipher API

Paul Rubin phr-pycrypt at nightsong.com
Tue Jan 28 18:52:34 CET 2003


    So ...  crypto built into Python would be great.  However, I do have
    some comments on your proposed API.

Thanks for the response.  Re your comments:

    1)       __call__(self, data, dir)
            where "dir must be 'd' (decrypt) or 'e' (encrypt)"

    seems a little odd.  Why not just have an 'encrypt' and 'decrypt'
    method.

The idea is that a codebook might be able to only encrypt, or only
decrypt, or setting up could be expensive.  I also wanted to simplify
the C API by having fewer entry points.  But maybe these reasons are
bogus.  Either way is ok.

    2)  class CBC (_mode):
         def __init__ (self, codebook, dir, iv=None):

    I like iv=None, if this means that iv is automatic (random, or whatever
    is required) when left as None.  Setting iv in the __init__ is wrong
    though ...  The iv can change per CBC encrypted data unit.

The iv in the cipher context does change as you encrypt stuff.  I
don't see any conflict between that with passing an IV to the init.

In CBC mode, the default IV is all zeros.  But in CFB mode, that's
much more dangerous, so you can't use a CFB context without supplying
an IV.

There's a set_random_iv operation but I think I'll remove it.  I don't
want the API to depend on having secure random numbers available.
If I do that, I'll make the iv arg mandatory for CFB mode.

    3) padding... I like that you're doing auto padding on the CBC mode.
    Pad modes can vary, so this would be better off as a pd class that was
    set at initialization

What other padding modes are important?  Can you describe what kind of
API you have in mind for a pad class?

    4) what's with the 'finalized'?  Why not let a cipher operate on more
    than one block/packet of data without having to create a new instance?

If the application uses a finalized context by accident, I wanted to
catch the error.  Making a new context is a pretty lightweight
operation (you can re-use the same codebook).  I guess 'final' could
somehow reset the context instead of locking it, or I could add a
reset operation.  I'll check the docs to see how the java cipher
classes do it.

Bryan Olson points out there should also be some standardization at
the C level, so the modes layer can call the cookbook layer without
going through the Python API.




More information about the python-crypto mailing list