FW: Rejected posting to [email protected]

Paul Lambert <[email protected]>
Newsgroups gmane.comp.python.cryptography
Message-ID <[email protected]>
>    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=20 only 
>decrypt, or setting up could be expensive.  I also wanted=20 to 
>simplify the C API by having fewer entry points.  But maybe=20 these 
>reasons are bogus.  Either way is ok.

Yes, bogus.  Make it simple ... encrypt/decrypt methods are more
intuitive.
>
>    2)  class CBC (_mode):
>         def __init__ (self, codebook, dir, iv=3DNone):
>
>    I like iv=3DNone, if this means that iv is automatic=20 (random, or

>whatever
>    is required) when left as None.  Setting iv in the=20 __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.=20  I 
>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.

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

Very bad.=20
>
>There's a set_random_iv operation but I think I'll remove it. =20 I 
>don't want the API to depend on having secure random numbers=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.=20
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.


>
>    3) padding... I like that you're doing auto padding on the=20 CBC 
>mode.
>    Pad modes can vary, so this would be better off as a pd=20 class 
>that was
>    set at initialization
>
>What other padding modes are important?  Can you describe what=20 kind 
>of API you have in mind for a pad class?

For example:


from crypto.cipher.rijndael import Rijndael
from crypto.cipher.base     import BlockCipher, padWithPadLen, noPadding
from crypto.errors          import BadKeySizeError

class AES(Rijndael):
    """ The AES algorithm is the Rijndael block cipher restricted to
block sizes of 128 bits
        and key sizes of 128, 192 or 256 bits """
    def __init__(self, key =3D None, padding =3D padWithPadLen(),
keySize=3D16):
        """ Initialize AES, keySize is in bytes """
        if  not (keySize =3D=3D 16 or keySize =3D=3D 24 or keySize =
=3D=3D 32) :
            raise BadKeySizeError, 'Illegal AES key size, must be 16,
24, or 32 bytes'

        Rijndael.__init__( self, key, padding=3Dpadding, =
keySize=3DkeySize, blockSize=3D16 )

        self.name       =3D 'AES'


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

There are a few other obscure ways that padding has been implemented.


>    4) what's with the 'finalized'?  Why not let a cipher=20 operate on

>more
>    than one block/packet of data without having to create a=20 new 
>instance?
>
>If the application uses a finalized context by accident, I=20 wanted to

>catch the error.  Making a new context is a pretty=20 lightweight 
>operation (you can re-use the same codebook).  I=20 guess 'final' could

>somehow reset the context instead of=20 locking it, or I could add a 
>reset operation.  I'll check the=20 docs to see how the java cipher 
>classes do it.

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

Seems like this would be more simple:

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

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

...  Modes should be wrappers, and yes the C API could /should align

I've put modes 'below' the base BlockCipher.... CBC should be able to
operate on any BlockCipher

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 =3D =
padWithPadLen()):

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

        alg1 =3D CBC( Rijndael(key, blockSize=3D32) )
        cipherText =3D alg1.encrypt(plainText)

... or for AES_CBC

"""     aes_cbc.py
"""

from crypto.cipher.aes  import AES
from crypto.cipher.cbc  import CBC
from crypto.cipher.base import BlockCipher, padWithPadLen, noPadding

class AES_CBC(CBC):
    """ AES encryption in CBC feedback mode """
    def __init__(self, key=3DNone, padding=3DpadWithPadLen(), =
keySize=3D16):
        CBC.__init__( self, AES(key, noPadding(), keySize), padding)
        self.name       =3D 'AES_CBC'



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.