From PaulLambert at WOODSIDENET.COM Tue Dec 3 02:24:14 2002 From: PaulLambert at WOODSIDENET.COM (Paul Lambert) Date: Mon, 2 Dec 2002 17:24:14 -0800 Subject: [PYTHON-CRYPTO] To OFB or not to OFB ? -> was RE: Re: some issues regarding OFB and CFB mode Message-ID: <3FFBC907DD03A34CA4410C5C745DEB12E7A12F@wnimail.woodsidenet.com> Eric, Thanks for the reply ... >Because it IS a library. >A useful library would not artificially limit what I can do. Perhaps ... however some limitations can prevent the less clueful from implementing a bad system design. Limitations also prevent feature bloat and reduce code size. >For example, what happens if I need to interoperate with a system that >uses a "badcipher" ? Just say no :-) Off hand, I can not think of any 'useful' Internet protocols that use OFB or CFB. There are some ANSI banking standards that MAY use these modes. If there were clear usage of these modes, they should obviously be implemented in a library. So ... I've implemented a 'pure' Python Rijndael/AES implementation. It supports ECB, CBC and CCM, but not OFB or CFB. These would be fairly easy to add, so I am curious to find what modes are really needed, versus just adding more acronyms to the list of supported modes. On this code ... I'll post a pointer to the latest version after I get my BXA approval. An early version leaked out at http://www.hifn.com/support/ccm.htm (note version 3.0 will have license updated to be 'open source'). The leaked version (not posted by me, please BXA don't come after me :-) was written for CCM interoperability testing. I don't plan to add OFB or CFB until I find a 'use' for these modes. Paul -----Original Message----- From: Eric Johnson [mailto:Eric.Johnson at GDAI.COM] Sent: Monday, December 02, 2002 1:21 PM To: PYTHON-CRYPTO at NIC.SURFNET.NL Subject: Re: some issues regarding OFB and CFB mode > Bad ciphers and modes should not be included in a crypto library without adequate justification. > >Just an opinion ... Because it IS a library. A useful library would not artificially limit what I can do. For example, what happens if I need to interoperate with a system that uses a "bad cipher" ? Eric From gouaich at LIRMM.FR Fri Dec 20 16:56:21 2002 From: gouaich at LIRMM.FR (GOUAICH Abdelkader) Date: Fri, 20 Dec 2002 16:56:21 +0100 Subject: [PYTHON-CRYPTO] Problem when installing the crypto package Message-ID: Hi there, I've downloaded the pycryto package and I am having some troubles when installing it. Here are my config: Windows 2000 Python 2.2 I'm using cygwin to make the setup. And here the command line that i am using: python setup.py build --compiler=mingw32 I have had already a problem with cl.exe but I have undestood that it war a compiler problem that is way I have changed the --compiler option. However I still having this message error: ... not copying .\PublicKey\__init__.py (output up-to-date) running build_ext building 'Crypto.Hash.MD2' extension skipping src/MD2.c (build\temp.win32-2.2\Release\md2.o up-to-date) writing build\temp.win32-2.2\Release\MD2.def C:\cygwin\bin\gcc.exe -mno-cygwin -mdll -static --entry _DllMain at 12 -s build\tem p.win32-2.2\Release\md2.o build\temp.win32-2.2\Release\MD2.def -Lc:\python22\lib s -lpython22 -o build\lib.win32-2.2\Crypto\Hash\MD2.pyd build\temp.win32-2.2\Release\md2.o(.text+0x444):MD2.c: undefined reference to `_ imp___Py_NoneStruct' build\temp.win32-2.2\Release\md2.o(.text+0x44c):MD2.c: undefined reference to `_ imp___Py_NoneStruct' build\temp.win32-2.2\Release\md2.o(.text+0x5b9):MD2.c: undefined reference to `_ imp__PyType_Type' error: command 'gcc' failed with exit status 1 Thanks, From phr-pycrypt at nightsong.com Fri Dec 20 21:04:15 2002 From: phr-pycrypt at nightsong.com (Paul Rubin) Date: Fri, 20 Dec 2002 20:04:15 -0000 Subject: [PYTHON-CRYPTO] Block cipher API again Message-ID: <20021220200415.1363.qmail@brouhaha.com> Hi, a while back we got in a long discussion about spec'ing and implementing block cipher API. The last thing I remember was proposing that the block cipher implementation should only implement one mode, namely a codebook lookup; all other operations should be done by a generic module that does codebook operations. Anyway I've written a prototype of what I meant by that. It's at: http://www.nightsong.com/phr/crypto/blockcipher.tgz Included are: 1. blockcipher.py: the prototype block cipher API. It implements ECB, CTR, and CBC modes, though it needs more features. OFB and CFB are currently unimplemented, though I should do those too. This is what I mean by a generic module. 2. lr64.py and lr128.py: two sample block cipher implementations, a 64-bit one and a 128-bit one. Both are straightforward codings of the Luby-Rackoff algorithm calling the built-in SHA module. 3. secrand.py: secure random number generator for *nix, that works by reading random bytes from /dev/urandom. It can generate random byte strings, or random integers of arbitrary size (useful for public key methods). I use this module all the time for all kinds of stuff. 4. test.py: a test harness for the above, just run it to self-test the other stuff. General plan: 1. Reach some consensus about what the blockcipher.py API should do, including a working implementation. This may take several passes and some discussion. 2. Reimplement the agreed-on API in C. This should be straightforward and I can do it. 3. Write Python-callable C implementations of AES, DES/3DES, and other ciphers as desired, that implement the codebook interface needed by the blockcipher API. Again straightforward, it just means putting Python wrappers around existing C ciphers. I can do this too. 4. Write a C implementation of secrand.py that works in Windows, that gets randomness from the Microsoft CAPI CryptGenRandom call. This will have to be done by someone with Windows development tools (I have none) but I can provide some assistance/advice if needed. The *nix implementation should also be tested in Solaris, MacOS, etc. 5. Submit all of the above to the Python maintainers for hopeful inclusion in 2.3. This may have to happen in the next few weeks. Comments are solicited. And are we up for this? Paul From gouaich at LIRMM.FR Sat Dec 21 13:25:13 2002 From: gouaich at LIRMM.FR (GOUAICH Abdelkader) Date: Sat, 21 Dec 2002 13:25:13 +0100 Subject: [PYTHON-CRYPTO] Problem when installing the crypto package In-Reply-To: Message-ID: I am always trying to intall the Crypto package under cygwin. And now I am having this error that I don't understand why it happens: running build_ext building 'Crypto.Hash.MD2' extension skipping src/MD2.c (build\temp.win32-2.2\Debug\md2.o up-to-date) writing build\temp.win32-2.2\Debug\MD2_d.def C:\cygwin\bin\gcc.exe -mno-cygwin -mdll -static --entry _DllMain at 12 -g build\tem p.win32-2.2\Debug\md2.o build\temp.win32-2.2\Debug\MD2_d.def -Lc:\python22\libs -lpython22_d -o build\lib.win32-2.2\Crypto\Hash\MD2_d.pyd /usr/lib/gcc-lib/i686-pc-mingw32/3.2/../../../../i686-pc-mingw32/bin/ld: cannot find -lpython22_d error: command 'gcc' failed with exit status 1 can any one help me... Thanks, From ngps at POST1.COM Sun Dec 29 18:13:07 2002 From: ngps at POST1.COM (Ng Pheng Siong) Date: Mon, 30 Dec 2002 01:13:07 +0800 Subject: [PYTHON-CRYPTO] [Announce] M2Crypto 0.08 Message-ID: <20021229171307.GB1381@vista.netmemetic.com> Hi, I present M2Crypto 0.08. Not quite in time for Christmas, but I managed to keep up my tradition of at-least-one-release-per-year for ZServerSSL. What's new: - SWIG 1.3.17. - setup.py does! - ZServerSSL for Zope 2.6.0. Please check it out: http://www.post1.com/home/ngps/m2 Happy New Year! -- Ng Pheng Siong * http://www.netmemetic.com