[PYTHON-CRYPTO] block ciphers

[Paul Rubin]

    Yes, bogus.  Make it simple ... encrypt/decrypt methods are more
    intuitive.

OK.  The current version on my site has the __call__ interface
replaced by encrypt/decrypt methods, and an optional direction arg in
the context constructor.

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

    Yes there is ... IV is per 'instance of encryption.  'init' should set
    Misc. parameters and keys.

I'm not sure what you mean by this.  A context is an instance of
encryption.

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

    Very bad.=3D20

Do you mean you want to be able to use CFB with zero IV?!  Or that
it's very bad to do that.  (Also, can you stop those =3D20's somehow?
I'm having to edit them by hand).

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

    Make the random base function be a optional parameter in the init.=3D20
    CBC does not need that strong of Ivs.  Other modes that need Special
    Ivs, (like CCM mode) need to create the IV themselves anyway. Default
    should always be automatic IV on encryption, and decryption.

Automatic random IV?  This depends on a secure RNG being available,
and there may not be one.  So there's a dilemma.  I'm somewhat
resistant to having this low-level block cipher module depend on a
highly OS-dependent thing like an RNG.  An RNG is important, but it's
a separate task.

    Make the random base function be a optional parameter in the init.=3D20
    CBC does not need that strong of Ivs.  Other modes that need Special
    Ivs, (like CCM mode) need to create the IV themselves anyway. Default
    should always be automatic IV on encryption, and decryption.

I don't understand CCM mode but I think the idea for now is to stick
with FIPS modes.

    Two intersing types of padding are 'padWithPadLen' and 'noPadding'.

Is 'padWithPadLen' the same as PKCS5?  I agree it's important to be
able to turn off padding.  I started coding a padding parameter but it
may be simpler to just get rid of padding altogether and let the
caller do it.  I'm taking the view that the goal is to make an C
implementation that does bulk encryption operations efficiently in the
necessary modes.

    But it's more code and effort to set-up the encryption.

    Seems like this would be more simple:

        alg = AES_CBC(key)
        cipherText1 = alg.encrypt(plainText1)
        cipherText2 = alg.encrypt(plainText2)

where alg.encrypt is supposed to generate IV's and stuff?  I think I'd
rather let some wrapper function do that.  Making a CBC context is
sort of the same deal as making a SHA or MD5 context.  You make a new
context every time you want to hash something new.  People are used to
it, it's not a big deal.

    class CBC(BlockCipher):
        """ The CBC class wraps block ciphers to make cipher block
        chaining (CBC) mode algorithms.  The initialization (IV) is
        automatic if set to None.  Padding is also automatic based on
        the Pad class used to initialize the algorithm"""

        def __init__(self, blockCipherInstance, padding = padWithPadLen()):

    ... For example, for 256bit Rijndael CBC:

            alg1 = CBC( Rijndael(key, blockSize=32) )
            cipherText = alg1.encrypt(plainText)

What happens if you want to encrypt a stream in multiple pieces?

What exactly is the padWithPadLen class supposed to do?

    >What should be done about padding the final plaintext, when the
    >feedback size is smaller than the block size?  Is it ok to just
    >require that the total plaintext consist of an integer number of
    >feedback units in those cases?

   No. Padding should be fully automatic and invisible to the end-user.

I'm somewhat taking the view that the end-user isn't going to call this
module directly.  It's supposed to be a C module for doing bulk encryption
operations efficiently, and end-user functions would be provided by
a higher level toolkit that calls the C module.

Thanks

--Paul R.