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