From phr-pycrypt at nightsong.com Mon Jan 27 19:22:06 2003 From: phr-pycrypt at nightsong.com (Paul Rubin) Date: Mon, 27 Jan 2003 18:22:06 -0000 Subject: [PYTHON-CRYPTO] Block cipher API again, AGAIN. Message-ID: <20030127182206.17320.qmail@brouhaha.com> Can folks here look at http://www.nightsong.com/phr/crypto/blockcipher.tgz It's the latest version of a proposed new API for block ciphers in Python. This API is loosely inspired by the corresponding Java classes and implements all the standard FIPS modes (its CFB mode is kind of half-assed right now). My intention is to reach some consensus on the API, then re-implement it in C along with the [3]DES and AES ciphers, and submit it to Guido for inclusion in Python 2.3. If it looks reasonable to you, I'll post that url to sci.crypt and comp.lang.python for further comments, but I want to catch any howlers before that. This all needs to get done pretty soon, in order to make it in time for 2.3. But Guido has expressed interest in it, so if we can pull this off, we will finally have real crypto in the standard Python distribution. Thanks Paul From phr-pycrypt at nightsong.com Mon Jan 27 19:41:03 2003 From: phr-pycrypt at nightsong.com (Paul Rubin) Date: Mon, 27 Jan 2003 18:41:03 -0000 Subject: [PYTHON-CRYPTO] random number module Message-ID: <20030127184103.17779.qmail@brouhaha.com> I'd like to submit a secure RNG module for Python 2.3. Like block ciphers, Guido has also expressed interest in this. I included a Linux implementation in the block cipher reference implementation that I just sent the url for: http://www.nightsong.com/phr/crypto/blockcipher.tgz It works by reading pseudo-random bytes from /dev/urandom, i.e. it lets the kernel do the heavy lifting. I've been using it for quite a while and I'm pretty happy with the interface. There needs to be something similar for Windows, that gets random bytes by calling CryptGenRandom function in the Windows CAPI, preferably using a CSP of the user's choice, but it's ok if it uses the standard Microsoft CSP. All that's needed is a dll with one or two entry points, to select the CSP and to read N random bytes with a CAPI call. I'd write this, except I'm mostly a Linux user and I don't have any Windows dev tools. Are there any Windows programmers here willing to do this? I'll provide whatever assistance I can, given that I can't compile or easily test the code. But I can help interpret the CAPI documentation if that's useful. Thanks. Paul From phr-pycrypt at nightsong.com Tue Jan 28 18:52:34 2003 From: phr-pycrypt at nightsong.com (Paul Rubin) Date: Tue, 28 Jan 2003 17:52:34 -0000 Subject: [PYTHON-CRYPTO] block cipher API Message-ID: <20030128175234.21156.qmail@brouhaha.com> 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. From phr-pycrypt at nightsong.com Wed Jan 29 07:23:45 2003 From: phr-pycrypt at nightsong.com (Paul Rubin) Date: Wed, 29 Jan 2003 06:23:45 -0000 Subject: [PYTHON-CRYPTO] cipher feedback mode Message-ID: <20030129062345.8524.qmail@brouhaha.com> I see the Java cipher api accepts feedback sizes down to 1 byte (8 bits) in CFB mode, but nothing smaller than that. However, the NIST test vectors for AES have some for 1-bit CFB mode. Does anyone care about 1-bit CFB mode? How about 2 bits or 4 bits? Is there any valid use for CFB mode where the feedback size doesn't divide the block size, like 5 bits or 23 bits? 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? What about the full-block case? I'm trying to think of what software applications use CFB mode at all. Anyone know of any? Thanks --Paul