From bram at GAWTH.COM Fri Nov 9 10:37:43 2001 From: bram at GAWTH.COM (Bram Cohen) Date: Fri, 9 Nov 2001 01:37:43 -0800 Subject: [PYTHON-CRYPTO] string <-> int conversion Message-ID: The binascii module, unfortunately, doesn't support base 256, and the binary encoding converter function I wrote seems to be ridiculously slow - is there one in the standard libs which I overlooked? -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From phr-pycrypt at nightsong.com Fri Nov 9 10:45:19 2001 From: phr-pycrypt at nightsong.com (Paul Rubin) Date: Fri, 9 Nov 2001 09:45:19 -0000 Subject: [PYTHON-CRYPTO] string <-> int conversion Message-ID: <20011109094519.7524.qmail@brouhaha.com> The python library has no direct base 256 conversion function and it's too late to get a patch into 2.2. However, converting long to hex with hex(...) and then using binascii for binary output, or binascii for binary to hex followed by long(h,16) to convert hex to long, is reasonably fast. From bram at GAWTH.COM Fri Nov 9 20:21:26 2001 From: bram at GAWTH.COM (Bram Cohen) Date: Fri, 9 Nov 2001 11:21:26 -0800 Subject: [PYTHON-CRYPTO] string <-> int conversion In-Reply-To: <20011109094519.7524.qmail@brouhaha.com> Message-ID: On Fri, 9 Nov 2001, Paul Rubin wrote: > The python library has no direct base 256 conversion function and it's > too late to get a patch into 2.2. However, converting long to hex > with hex(...) and then using binascii for binary output, or binascii > for binary to hex followed by long(h,16) to convert hex to long, is > reasonably fast. Thanks, I feel stupid now. I cleaned up my routines to work that way, here are the nicer versions - from binascii import b2a_hex, a2b_hex def int_to_binary(numin, size): x = hex(numin)[2:] if x[-1] == 'L': x = x[:-1] if len(x) % 2 == 1: x = '0' + x x = a2b_hex(x) x = ('\000' * (size - len(x))) + x return x def binary_to_int(s): return long(b2a_hex(s), 16) I hate hate hate the int/long distinction and will do a dance on long()'s grave when it's gone. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From akuchlin at mems-exchange.org Sat Nov 17 04:47:10 2001 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Sat, 17 Nov 2001 03:47:10 -0000 Subject: [PYTHON-CRYPTO] Call for people wanting CVS access to pycrypto Message-ID: <20011117034710.10052.qmail@mozart.cnri.reston.va.us> The pycrypto-checkins list is now up and running, so I'll repeat an earlier request: send me your SourceForge ID if you want check-in privileges to the CVS tree for the Python Cryptography Toolkit project on Sourceforge. See http://www.sf.net/projects/pycrypto/ for pointers to the CVS tree and the pycrypto-checkins mailing list. Also, if you have a crypto-related project of your own and want to make the CVS publicly available, I'll happily add them to the CVS tree as separate modules. --amk From akuchlin at mems-exchange.org Tue Nov 20 01:25:56 2001 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Mon, 19 Nov 2001 19:25:56 -0500 Subject: [PYTHON-CRYPTO] Near-term projects for pycrypto Message-ID: <20011119192556.A8420@ute.mems-exchange.org> Here are some things I'd like to do with the pycrypto code. Reactions? 1) Break backward compatibility. The interfaces were invented around 1995, back when I was younger and dumber. I'd like to clean them up, cruelly breaking backward compatibility where necessary, and release the new code as version 2.0 to signal the magnitude of the changes. While we have the chance, we can also drop useless code, rename packages and classes, or whatever. 2) Is there any point in keeping the implementations of MD5 and SHA if Python comes with them? We could just change Crypto/Hash/MD5.py to just 'from md5 import *', and ditto for Crypto/Hash/SHA.py. 3) Get rid of the clumsily generated source files and just keep everything straightforward. For hash modules, this would be straightforward. However, I don't know how to fix block encryption modules properly. The original purpose of autogenerating everything was to re-use the tricky and error-prone code for the various feedback modes, while hopefully avoiding the overhead of doing a C function call on every block. Maybe the C function overhead isn't worth saving. If so, then perhaps we could write a single C file that implemented the feedback modes as a library. Individual encryption modules would then define a function to encrypt a single block, another for decrypting a single block, and then pass these functions to the code in the library. (We'd have to finalize a block encryption API to do that, hopefully defining it in the Block Encryption PEP at the same time.) 4) Remove the export/not-for-export cruft. 5) Modernize the code to current standards (Distutils installation, docstrings, naming conventions). We might rename the package from 'Crypto' to 'crypto', or some other name. 6) Discard some of the more obscure algorithms (HAVAL, Diamond, Skipjack, maybe CAST, RC5 and IDEA, too) and add AES, adopting the principle of well-tested and commonly used algorithms, not every single one that gets invented. 7) Public-key stuff: should it remain in this package, or should it be scrapped and the scope restricted to hashing and block encryption? Public-key is much harder to define and implement, so I think splitting it out into a separate distribution is the right thing to do. --amk From rsalz at ZOLERA.COM Tue Nov 20 03:27:21 2001 From: rsalz at ZOLERA.COM (Rich Salz) Date: Mon, 19 Nov 2001 21:27:21 -0500 Subject: [PYTHON-CRYPTO] Near-term projects for pycrypto References: <20011119192556.A8420@ute.mems-exchange.org> Message-ID: <3BF9BF89.A0A61B9A@zolera.com> My reactions: break compatibility, call it 2.0, and for now drop MD5 and SHA. Later, add a SHA wrapper if there's a significant API style emerging. (MD5 is to be avoided.) I totally agree that we should avoid tricky code for efficiency; let's get it clean and right first and then speed it up if that's necessary. We can play games like sharing string buffers as the first efficiency trick. All your other ideas are a straight "+1", except keep IDEA for PGP implementors. I'd like to be able to build the Python interfaces on top of SWIG'd openssl, but I wouldn't hold anything up because of that. /r$ -- Zolera Systems, Securing web services (XML, SOAP, Signatures, Encryption) http://www.zolera.com From phr-pycrypt at nightsong.com Tue Nov 20 03:56:33 2001 From: phr-pycrypt at nightsong.com (Paul Rubin) Date: Tue, 20 Nov 2001 02:56:33 -0000 Subject: [PYTHON-CRYPTO] Near-term projects for pycrypto Message-ID: <20011120025633.28664.qmail@brouhaha.com> Here are some things I'd like to do with the pycrypto code. Reactions? How about saying what the goals of pycrypto are, before going into specific changes? But I'll react based on the idea that it's a general purpose crypto lib. 1) Break backward compatibility. The interfaces were invented around 1995, back when I was younger and dumber. I'd like to clean them up, cruelly breaking backward compatibility where necessary, and release the new code as version 2.0 to signal the magnitude of the changes. While we have the chance, we can also drop useless code, rename packages and classes, or whatever. This depends on how many people are using the old version. If many, then preserve compatibility. I'm not using the old version so I don't care :). 2) Is there any point in keeping the implementations of MD5 and SHA if Python comes with them? We could just change Crypto/Hash/MD5.py to just 'from md5 import *', and ditto for Crypto/Hash/SHA.py. If the pycrypto implementations are better (e.g., faster), then keep them. Otherwise drop them. 3) Get rid of the clumsily generated source files and just keep everything straightforward. For hash modules, this would be straightforward. However, I don't know how to fix block encryption modules properly. The original purpose of autogenerating everything was to re-use the tricky and error-prone code for the various feedback modes, while hopefully avoiding the overhead of doing a C function call on every block. Unless there's a specific reason to supports weird feedback modes, drop them. Support CBC mode, resumably and with PKCS5 padding. 4) Remove the export/not-for-export cruft. If you're outside the US, sure. If in the US, I don't know. 5) Modernize the code to current standards (Distutils installation, docstrings, naming conventions). We might rename the package from 'Crypto' to 'crypto', or some other name. OK. 6) Discard some of the more obscure algorithms (HAVAL, Diamond, Skipjack, maybe CAST, RC5 and IDEA, too) and add AES, adopting the principle of well-tested and commonly used algorithms, not every single one that gets invented. If IDEA is kept for the sake of PGP 2.x interoperation, then MD5 also has to be kept (at least in the interface--the python implementation is fine for that). In principle though I support dropping unneeded and/or patented algorithms. Keep DES, 3DES, and maybe RC4. Add AES, and maybe SHA256 and SHA512. Drop the rest. OTOH I'd like to propose supporting SHA in output feedback mode as a stream cipher. The reason is that it can be implemented efficiently in pure Python using the built-in sha library. My own crypto lib uses it for that reason. 7) Public-key stuff: should it remain in this package, or should it be scrapped and the scope restricted to hashing and block encryption? Public-key is much harder to define and implement, so I think splitting it out into a separate distribution is the right thing to do. Public key should stay. Its definition and implementation should follow IEEE P1363. Also, a Yarrow-like PRNG should be added. From bram at GAWTH.COM Tue Nov 20 04:10:47 2001 From: bram at GAWTH.COM (Bram Cohen) Date: Mon, 19 Nov 2001 19:10:47 -0800 Subject: [PYTHON-CRYPTO] Near-term projects for pycrypto In-Reply-To: <20011119192556.A8420@ute.mems-exchange.org> Message-ID: On Mon, 19 Nov 2001, Andrew Kuchling wrote: > 2) Is there any point in keeping the implementations of MD5 and SHA if > Python comes with them? I say nuke 'em > 4) Remove the export/not-for-export cruft. Yes! > 6) Discard some of the more obscure algorithms (HAVAL, Diamond, > Skipjack, maybe CAST, RC5 and IDEA, too) Yes! Those are nothing but temptation to naive would-be protocol designers. > and add AES Most definitely, not having AES would be just plain embarassing. > 7) Public-key stuff: should it remain in this package, or should it be > scrapped and the scope restricted to hashing and block encryption? > Public-key is much harder to define and implement, so I think > splitting it out into a separate distribution is the right thing to > do. With the built-in pow() function most public-key things are just a few lines, and given the difficulty of making APIs match up exactly with what people will want later I'd say it's best to let people do the few lines of code themselves. Exceptions include random prime generation, gcf and maybe dsa (since dsa's API is fairly clear.) I'm probably missing a few others. In any case, I agree that public key is a fairly separate set of issues, and am in favor of it being separated out. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From bram at GAWTH.COM Tue Nov 20 04:23:29 2001 From: bram at GAWTH.COM (Bram Cohen) Date: Mon, 19 Nov 2001 19:23:29 -0800 Subject: [PYTHON-CRYPTO] Near-term projects for pycrypto In-Reply-To: <20011120025633.28664.qmail@brouhaha.com> Message-ID: On Tue, 20 Nov 2001, Paul Rubin wrote: > 2) Is there any point in keeping the implementations of MD5 and SHA if > Python comes with them? > > If the pycrypto implementations are better (e.g., faster), then keep them. > Otherwise drop them. If they're faster, they can be substituted in with a later version of Python. > OTOH I'd like to propose supporting SHA in output feedback mode as a > stream cipher. The reason is that it can be implemented efficiently > in pure Python using the built-in sha library. My own crypto lib uses > it for that reason. sha1 has some weaknesses in that mode, although they may be theoretical. It's also extremely slow - there's a fair amount of padding sha1 does on the theory that most things hashed are quite large and a fixed amount of padding is no big deal, and sha1 isn't all that fast to begin with. An altogether more reasonable stream cipher is AES in counter mode, which is what I'm using. > Also, a Yarrow-like PRNG should be added. hear hear! I have an entropy.entropy() function which takes a number and returns a random string containing that number of bytes. Under unix it initially seeds from /dev/random, but under Windows I had to completely punt it with something very ugly and not terribly secure. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From phr-pycrypt at nightsong.com Tue Nov 20 08:25:08 2001 From: phr-pycrypt at nightsong.com (Paul Rubin) Date: Tue, 20 Nov 2001 07:25:08 -0000 Subject: [PYTHON-CRYPTO] Near-term projects for pycrypto Message-ID: <20011120072508.30514.qmail@brouhaha.com> > 6) Discard some of the more obscure algorithms (HAVAL, Diamond, > Skipjack, maybe CAST, RC5 and IDEA, too) Yes! Those are nothing but temptation to naive would-be protocol designers. This is a good reason to dump them, and is relevant to the public key issue. With the built-in pow() function most public-key things are just a few lines, and given the difficulty of making APIs match up exactly with what people will want later I'd say it's best to let people do the few lines of code themselves. Exceptions include random prime generation, gcf and maybe dsa (since dsa's API is fairly clear.) I'm probably missing a few others. The thing is, public key is very easy to screw up. Look at the controversy over OAEP padding for RSA for example, and OAEP was designed by people who knew what they were doing. Recently I had to review someone's RSA implementation and they used no random padding at all. The same logic that says to remove obscure block ciphers also says: implement public key and do it right, and remove the need for naive implementers to mess it up. In any case, I agree that public key is a fairly separate set of issues, and am in favor of it being separated out. I don't see why it's separate--if there's really something different about it that I'm missing, then fine, separate it out, but it shouldn't be simply dropped. > If the pycrypto [sha,md5] implementations are better (e.g., faster), > then keep them. Otherwise drop them. If they're faster, they can be substituted in with a later version of Python. I don't think it's Python's job to necessarily have the fastest implementations of functions like this. Think of doing matrix arithmetic in Python vs. doing it in Numerical Python; or bignum arithmetic in Python vs. gmpy. It's reasonable for Python to have some generic, portable implementation of a given function, while a specialized library duplicates the functionality in a more highly tuned implementation. For example, the fastest SHA implementation might have conditionalized hand-tuned assembly code for 10 different machines. The Python maintainers would never ship such a thing, but it's reasonable for Pycrypto to include it. > OTOH I'd like to propose supporting SHA in output feedback mode > as a stream cipher. The reason is that it can be implemented > efficiently in pure Python using the built-in sha library. My > own crypto lib uses it for that reason. sha1 has some weaknesses in that mode, although they may be theoretical. It's also extremely slow - there's a fair amount of padding sha1 does on the theory that most things hashed are quite large and a fixed amount of padding is no big deal, and sha1 isn't all that fast to begin with. An altogether more reasonable stream cipher is AES in counter mode, which is what I'm using. If AES is made part of the standard python library, then that's great. I'm talking about what can be done with just the standard library and no add-ons. I haven't been able to come up with anything faster than SHA-OFB that has any hope of decent security. It's 4x faster than RC4 coded in Python. > Also, a Yarrow-like PRNG should be added. hear hear! I have an entropy.entropy() function which takes a number and returns a random string containing that number of bytes. Under unix it initially seeds from /dev/random, but under Windows I had to completely punt it with something very ugly and not terribly secure. Maybe Yarrow can be ported to Python for Windows and included in pycrypt. Under Unix, it suffices to use /dev/urandom and let the system take care of entropy gathering. I guess it's ok to have a flag to insist on /dev/random instead of /dev/urandom. From mal at LEMBURG.COM Tue Nov 20 11:05:59 2001 From: mal at LEMBURG.COM (M.-A. Lemburg) Date: Tue, 20 Nov 2001 11:05:59 +0100 Subject: [PYTHON-CRYPTO] Near-term projects for pycrypto References: <20011119192556.A8420@ute.mems-exchange.org> Message-ID: <3BFA2B07.991E5983@lemburg.com> Andrew Kuchling wrote: > > 4) Remove the export/not-for-export cruft. Could someone please summarize what the current state of affairs is for US exports ? AFAIK, you'll have to get an official "license" from the government to be able to legally export the code. If so, then this should be on the list of TODOs. > 5) Modernize the code to current standards (Distutils installation, > docstrings, naming conventions). We might rename the package from > 'Crypto' to 'crypto', or some other name. +1 > 6) Discard some of the more obscure algorithms (HAVAL, Diamond, > Skipjack, maybe CAST, RC5 and IDEA, too) and add AES, adopting the > principle of well-tested and commonly used algorithms, not every > single one that gets invented. +1 (except for dropping IDEA and RC5 -- they're patented, but not in every corner of the world; and then if someone wants to use it, paying the license fee is well worth the gained interop capability) > 7) Public-key stuff: should it remain in this package, or should it be > scrapped and the scope restricted to hashing and block encryption? > Public-key is much harder to define and implement, so I think > splitting it out into a separate distribution is the right thing to > do. 8) Provide drop-in support for extensions/drivers like amkCrypto/mxCrypto. There should be some way to register these drivers in your package, e.g. by defining a certain subdirectory to be a place where pycrypto looks for these drivers at startup time. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From p.mayers at IC.AC.UK Tue Nov 20 11:53:53 2001 From: p.mayers at IC.AC.UK (Mayers, Philip J) Date: Tue, 20 Nov 2001 10:53:53 -0000 Subject: [PYTHON-CRYPTO] Near-term projects for pycrypto Message-ID: Just for fun, how about this - implement the generalised public key function listed in Applied Crypto (can't recall the name off the top of my head - the one that makes El Gamal, RSA, DSA etc. all subsets of the same basic algorithm). Or, drop it, and wrap OpenSSL's public key stuff. What's your take on putting SSL/TLS in there? Zope's ZServer using one crypto library.. mmm... Regards, Phil +------------------------------------------+ | Phil Mayers | | Network & Infrastructure Group | | Information & Communication Technologies | | Imperial College | +------------------------------------------+ -----Original Message----- From: Andrew Kuchling [mailto:akuchlin at MEMS-EXCHANGE.ORG] Sent: 20 November 2001 00:26 To: PYTHON-CRYPTO at NIC.SURFNET.NL Subject: [PYTHON-CRYPTO] Near-term projects for pycrypto 7) Public-key stuff: should it remain in this package, or should it be scrapped and the scope restricted to hashing and block encryption? Public-key is much harder to define and implement, so I think splitting it out into a separate distribution is the right thing to do. --amk From peter_shannon at YAHOO.COM Tue Nov 20 13:30:11 2001 From: peter_shannon at YAHOO.COM (=?iso-8859-1?q?Peter=20Shannon?=) Date: Tue, 20 Nov 2001 12:30:11 +0000 Subject: [PYTHON-CRYPTO] POW Message-ID: <20011120123011.43149.qmail@web13307.mail.yahoo.com> Hi All, just wanted to send you a note to say I've just released quite an important update to the project I've been working on. If you want to check it out you can find it at http://sourceforge.net/projects/pow. If you have any comments or would like to help, it would be greatly appreciated. Cheers, Peter Shannon. __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com From rsalz at ZOLERA.COM Tue Nov 20 15:21:08 2001 From: rsalz at ZOLERA.COM (Rich Salz) Date: Tue, 20 Nov 2001 09:21:08 -0500 Subject: [PYTHON-CRYPTO] TSU NOTIFICATION Message-ID: <3BFA66D4.F53A0E07@zolera.com> SUBMISSION TYPE: TSU SUBMITTED BY: Rich Salz SUBMITTED FOR: Python crypto Special Interest Group POINT OF CONTACT: python-crypto at nic.surfnet.nl ; rsalz at zolera.com PHONE and/or FAX: 781 789 3974 (cell) MANUFACTURER: (if relevant) n/a PRODUCT NAME/MODEL #: n/a ECCN: 5D002 NOTIFICATION: http://sourceforge.net/projects/pycrypto/ -- Zolera Systems, Your Key to Online Integrity Securing Web services: XML, SOAP, Dig-sig, Encryption http://www.zolera.com From rsalz at ZOLERA.COM Tue Nov 20 15:22:22 2001 From: rsalz at ZOLERA.COM (Rich Salz) Date: Tue, 20 Nov 2001 09:22:22 -0500 Subject: [PYTHON-CRYPTO] Near-term projects for pycrypto References: <20011119192556.A8420@ute.mems-exchange.org> <3BFA2B07.991E5983@lemburg.com> Message-ID: <3BFA671E.F7C654C7@zolera.com> > Could someone please summarize what the current state of affairs > is for US exports ? AFAIK, you'll have to get an official > "license" from the government to be able to legally export the > code. If so, then this should be on the list of TODOs. I just took another look at the US Gov't site, www.bxa.doc.gov. It's amazingly clear right now -- they even have "Encryption" as a link on their main page. :) For open source (which they call "publicly available"), the details are at [1]. In short, you only need to send an email with the URL to crypt at bxa.doc.gov. I'm about to do so, and will CC this list. (Also, Cc to exports at crypto.com so "we" have a public record.) The OpenSSL group has had expert legal advice (Dan Bernstein's EFF lawyer, Cindy Cohn) and they feel comfortable with US contributions as long as they are Cc'd to the BXA email address. (Exporting *products* is almost as easy, as long as you avoid a specific set (Libya, et al). We just went through the process.) [1] http://www.bxa.doc.gov/Encryption/PubAvailEncSourceCodeNofify.html /r$ -- Zolera Systems, Your Key to Online Integrity Securing Web services: XML, SOAP, Dig-sig, Encryption http://www.zolera.com From akuchlin at mems-exchange.org Tue Nov 20 16:09:04 2001 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Tue, 20 Nov 2001 10:09:04 -0500 Subject: [PYTHON-CRYPTO] Near-term projects for pycrypto In-Reply-To: <3BFA2B07.991E5983@lemburg.com>; from mal@LEMBURG.COM on Tue, Nov 20, 2001 at 11:05:59AM +0100 References: <20011119192556.A8420@ute.mems-exchange.org> <3BFA2B07.991E5983@lemburg.com> Message-ID: <20011120100904.D8420@ute.mems-exchange.org> On Tue, Nov 20, 2001 at 11:05:59AM +0100, M.-A. Lemburg wrote: >> 6) Discard some of the more obscure algorithms (HAVAL, Diamond, >> Skipjack, maybe CAST, RC5 and IDEA, too) and add AES, adopting the > >+1 (except for dropping IDEA and RC5 -- they're patented, but not in >every corner of the world; and then if someone wants to use it, paying That leaves CAST as the only cipher to be dropped; is CAST actually used in any standards or specifications? --amk From akuchlin at mems-exchange.org Tue Nov 20 16:39:28 2001 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Tue, 20 Nov 2001 10:39:28 -0500 Subject: [PYTHON-CRYPTO] Near-term projects for pycrypto In-Reply-To: <20011120025633.28664.qmail@brouhaha.com>; from phr-pycrypt@NIGHTSONG.COM on Tue, Nov 20, 2001 at 02:56:33AM -0000 References: <20011120025633.28664.qmail@brouhaha.com> Message-ID: <20011120103928.E8420@ute.mems-exchange.org> On Tue, Nov 20, 2001 at 02:56:33AM -0000, Paul Rubin wrote: >How about saying what the goals of pycrypto are, before going into >specific changes? But I'll react based on the idea that it's a >general purpose crypto lib. General purpose, yes, but I'd like to define public-key stuff as a separate package because it's much less clear what the interface for public-key should be. For example, in another e-mail you suggest that IEEE P.1363 should be implemented, but it's not clear why that's preferable to PKCS. Perhaps 1363 just formalizes PKCS, in which case the example Block encryption should be much easier; after we've squabbled over the interface a bit and settled on the list of supported feedback modes, the rest is just a matter of implementation, and it should be possible to get a release done in a month or two. >If the pycrypto implementations are better (e.g., faster), then keep them. >Otherwise drop them. No difference -- the SHA module included with Python is a tidied-up version of the pycrypto code. --amk From p.mayers at IC.AC.UK Tue Nov 20 18:03:52 2001 From: p.mayers at IC.AC.UK (Mayers, Philip J) Date: Tue, 20 Nov 2001 17:03:52 -0000 Subject: [PYTHON-CRYPTO] Near-term projects for pycrypto Message-ID: Yes, I know - using the M2Crypto library. That was what I was referring to (not that there is anything *wrong* with M2Crypto - I just dislike using two libraries where I can use one). Regards, Phil +------------------------------------------+ | Phil Mayers | | Network & Infrastructure Group | | Information & Communication Technologies | | Imperial College | +------------------------------------------+ -----Original Message----- From: Ng Pheng Siong [mailto:ngps at post1.com] Sent: 20 November 2001 16:59 To: Mayers, Philip J Cc: PYTHON-CRYPTO at NIC.SURFNET.NL Subject: Re: Near-term projects for pycrypto On Tue, Nov 20, 2001 at 10:53:53AM -0000, Mayers, Philip J wrote: > What's your take on putting SSL/TLS in there? Zope's ZServer using one > crypto library.. mmm... ZServerSSL has existed for two years already: http://www.post1.com/home/ngps Cheers. -- Ng Pheng Siong * http://www.post1.com/home/ngps From mal at LEMBURG.COM Tue Nov 20 16:31:20 2001 From: mal at LEMBURG.COM (M.-A. Lemburg) Date: Tue, 20 Nov 2001 16:31:20 +0100 Subject: [PYTHON-CRYPTO] Near-term projects for pycrypto References: <20011119192556.A8420@ute.mems-exchange.org> <3BFA2B07.991E5983@lemburg.com> <3BFA671E.F7C654C7@zolera.com> Message-ID: <3BFA7748.887C5218@lemburg.com> Rich Salz wrote: > > > Could someone please summarize what the current state of affairs > > is for US exports ? AFAIK, you'll have to get an official > > "license" from the government to be able to legally export the > > code. If so, then this should be on the list of TODOs. > > I just took another look at the US Gov't site, www.bxa.doc.gov. It's > amazingly clear right now -- they even have "Encryption" as a link on > their main page. :) For open source (which they call "publicly > available"), the details are at [1]. In short, you only need to send an > email with the URL to crypt at bxa.doc.gov. I'm about to do so, and will > CC this list. (Also, Cc to exports at crypto.com so "we" have a public > record.) Great ! > The OpenSSL group has had expert legal advice (Dan Bernstein's EFF > lawyer, Cindy Cohn) and they feel comfortable with US contributions as > long as they are Cc'd to the BXA email address. Perhaps we should put their email address on the CVS checkin mailing list ;-) > (Exporting *products* is almost as easy, as long as you avoid a specific > set (Libya, et al). We just went through the process.) With "products" I assume you mean closed-source software, right ? > [1] http://www.bxa.doc.gov/Encryption/PubAvailEncSourceCodeNofify.html > /r$ Thanks, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at LEMBURG.COM Tue Nov 20 16:34:40 2001 From: mal at LEMBURG.COM (M.-A. Lemburg) Date: Tue, 20 Nov 2001 16:34:40 +0100 Subject: [PYTHON-CRYPTO] Near-term projects for pycrypto References: Message-ID: <3BFA7810.FFA3F8C3@lemburg.com> "Mayers, Philip J" wrote: > > Just for fun, how about this - implement the generalised public key function > listed in Applied Crypto (can't recall the name off the top of my head - the > one that makes El Gamal, RSA, DSA etc. all subsets of the same basic > algorithm). > > Or, drop it, and wrap OpenSSL's public key stuff. As suggested in another posting: I'd go with the driver paradigm here, ie. provide Python or C extension defaults and high-performance OpenSSL implementation as optional driver. BTW, I've extended mxCrypto to support RSA and DSA; it's just not ready for prime-time yet. > What's your take on putting SSL/TLS in there? Zope's ZServer using one > crypto library.. mmm... I suppose M2Crypto could be used as a driver as well. It also links to OpenSSL. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From rsalz at ZOLERA.COM Tue Nov 20 18:08:20 2001 From: rsalz at ZOLERA.COM (Rich Salz) Date: Tue, 20 Nov 2001 12:08:20 -0500 Subject: [PYTHON-CRYPTO] Near-term projects for pycrypto References: <20011119192556.A8420@ute.mems-exchange.org> <3BFA2B07.991E5983@lemburg.com> <3BFA671E.F7C654C7@zolera.com> <3BFA7748.887C5218@lemburg.com> Message-ID: <3BFA8E04.7C25BA9@zolera.com> > > (Exporting *products* is almost as easy, as long as you avoid a specific > > set (Libya, et al). We just went through the process.) > > With "products" I assume you mean closed-source software, right ? yes. -- Zolera Systems, Your Key to Online Integrity Securing Web services: XML, SOAP, Dig-sig, Encryption http://www.zolera.com From ngps at POST1.COM Tue Nov 20 17:58:44 2001 From: ngps at POST1.COM (Ng Pheng Siong) Date: Wed, 21 Nov 2001 00:58:44 +0800 Subject: [PYTHON-CRYPTO] Near-term projects for pycrypto In-Reply-To: ; from p.mayers@IC.AC.UK on Tue, Nov 20, 2001 at 10:53:53AM -0000 References: Message-ID: <20011121005844.C1628@madcap.dyndns.org> On Tue, Nov 20, 2001 at 10:53:53AM -0000, Mayers, Philip J wrote: > What's your take on putting SSL/TLS in there? Zope's ZServer using one > crypto library.. mmm... ZServerSSL has existed for two years already: http://www.post1.com/home/ngps Cheers. -- Ng Pheng Siong * http://www.post1.com/home/ngps From kalath at lycos.com Wed Nov 21 03:38:47 2001 From: kalath at lycos.com (Mark Brady) Date: Wed, 21 Nov 2001 02:38:47 0000 Subject: [PYTHON-CRYPTO] Near-term projects for pycrypto Message-ID: I could implement a Java JCE (Java Cryptography Extension) based driver so that Jython could use the pycrypo interface. It's cool to see pycrypto take off. Mark. -- On Tue, 20 Nov 2001 16:34:40 M.-A. Lemburg wrote: >"Mayers, Philip J" wrote: >> >> Just for fun, how about this - implement the generalised public key function >> listed in Applied Crypto (can't recall the name off the top of my head - the >> one that makes El Gamal, RSA, DSA etc. all subsets of the same basic >> algorithm). >> >> Or, drop it, and wrap OpenSSL's public key stuff. > >As suggested in another posting: I'd go with the driver paradigm >here, ie. provide Python or C extension defaults and high-performance >OpenSSL implementation as optional driver. > >BTW, I've extended mxCrypto to support RSA and DSA; it's just not ready >for prime-time yet. > >> What's your take on putting SSL/TLS in there? Zope's ZServer using one >> crypto library.. mmm... > >I suppose M2Crypto could be used as a driver as well. It also >links to OpenSSL. > >-- >Marc-Andre Lemburg >CEO eGenix.com Software GmbH >______________________________________________________________________ >Consulting & Company: http://www.egenix.com/ >Python Software: http://www.lemburg.com/python/ > From phr-pycrypt at nightsong.com Wed Nov 21 18:52:38 2001 From: phr-pycrypt at nightsong.com (Paul Rubin) Date: Wed, 21 Nov 2001 17:52:38 -0000 Subject: [PYTHON-CRYPTO] Near-term projects for pycrypto Message-ID: <20011121175238.19016.qmail@brouhaha.com> Hi, I'm away for the week and will have spotty email access til I get back. A couple quick comments on last few messages: 1) IEEE 1363/P1363a has lots of stuff not in PKCS, including an improved RSA padding scheme (OAEP as specified in PKCS1 has some problems), and specifications for various elliptic curve schemes. I think Pycrypt should support at least one EC scheme. For new applications EC is preferable to RSA or DL schemes most of the time. 2) The generalized scheme from Applied Cryptography is just for DL variants (stuff like DSA), not RSA. It's a cool theoretical result but IMO there's no point in implementing it. It just gives the user more ways to choose unsafe variants, and doesn't have any advantages. 3) Supporting the OpenSSL stuff is IMO only worthwhile if the intention is to support actual SSL. 4) I don't see any point in supporting RC5 for interoperability since I don't know of any important applications that use it. IDEA is used in legacy PGP versions but is only worth supporting in Pycrypt if someone is going to write a Python version of PGP. Otherwise, drop IDEA. 5) I do see some point to supporting a generic fast 64-bit block cipher like CAST or Blowfish, since some apps want 64-bit ciphers, and 3DES is slow. 6) The above is from the philosophical standpoint that Pycrypt is mainly supposed to give app writers a way to put crypto into their applications without being crypto experts. The alternate view it's more intended as a toolkit for experts. Either view is ok with me, but the designers should make a clear decision about what the goals are, rather than muddling around between various possible goals. From akuchlin at mems-exchange.org Wed Nov 21 21:39:39 2001 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Wed, 21 Nov 2001 15:39:39 -0500 Subject: [PYTHON-CRYPTO] Near-term projects for pycrypto In-Reply-To: <20011121175238.19016.qmail@brouhaha.com>; from phr-pycrypt@NIGHTSONG.COM on Wed, Nov 21, 2001 at 05:52:38PM -0000 References: <20011121175238.19016.qmail@brouhaha.com> Message-ID: <20011121153939.A16090@ute.mems-exchange.org> On Wed, Nov 21, 2001 at 05:52:38PM -0000, Paul Rubin wrote: >3) Supporting the OpenSSL stuff is IMO only worthwhile if the intention >is to support actual SSL. That's a good question; should we concentrate on wrapping OpenSSL or some other library? If we wrap OpenSSL, , for example, then the mxCrypto code can be used. Advantages of using a library are: * No need to implement the algorithms. * Someone else can write platform-specific assembly for better performance. Disadvantages: * the library is one more thing to install. * the modules may get more complicated in order to present a consistent interface (if the underlying library doesn't support a feedback mode we do, for example). --amk From akuchlin at mems-exchange.org Wed Nov 21 21:43:28 2001 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Wed, 21 Nov 2001 15:43:28 -0500 Subject: [PYTHON-CRYPTO] Near-term projects for pycrypto In-Reply-To: <3BFA671E.F7C654C7@zolera.com>; from rsalz@ZOLERA.COM on Tue, Nov 20, 2001 at 09:22:22AM -0500 References: <20011119192556.A8420@ute.mems-exchange.org> <3BFA2B07.991E5983@lemburg.com> <3BFA671E.F7C654C7@zolera.com> Message-ID: <20011121154328.B16090@ute.mems-exchange.org> On Tue, Nov 20, 2001 at 09:22:22AM -0500, Rich Salz wrote: >The OpenSSL group has had expert legal advice (Dan Bernstein's EFF >lawyer, Cindy Cohn) and they feel comfortable with US contributions as >long as they are Cc'd to the BXA email address. Hmm... what do we do with a CVS tree? I'd think it's easier (and more polite!) to just notify the BXA address of every new release, rather than to put them on the -checkins list. --amk From mal at LEMBURG.COM Wed Nov 21 21:47:49 2001 From: mal at LEMBURG.COM (M.-A. Lemburg) Date: Wed, 21 Nov 2001 21:47:49 +0100 Subject: [PYTHON-CRYPTO] Near-term projects for pycrypto References: <20011121175238.19016.qmail@brouhaha.com> Message-ID: <3BFC12F5.10EAEC25@lemburg.com> Paul Rubin wrote: > > 3) Supporting the OpenSSL stuff is IMO only worthwhile if the intention > is to support actual SSL. OpenSSL has very good low-level cipher implementations which are already supported in amkCrypto/mxCrypto. > 4) I don't see any point in supporting RC5 for interoperability since > I don't know of any important applications that use it. IDEA is used > in legacy PGP versions but is only worth supporting in Pycrypt if > someone is going to write a Python version of PGP. Otherwise, drop > IDEA. -1. RC5 can be used in SSL/TLS, IDEA is common in commercial crypto implementations (hardware and software). > 5) I do see some point to supporting a generic fast 64-bit block > cipher like CAST or Blowfish, since some apps want 64-bit ciphers, and > 3DES is slow. > > 6) The above is from the philosophical standpoint that Pycrypt is > mainly supposed to give app writers a way to put crypto into their > applications without being crypto experts. The alternate view it's > more intended as a toolkit for experts. Either view is ok with me, > but the designers should make a clear decision about what the goals > are, rather than muddling around between various possible goals. IMHO, we should focus on designing interfaces and only think about the possible driver implementation later on (most of these are already available and only need to be adapted to the interfaces). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From akuchlin at mems-exchange.org Wed Nov 21 22:10:26 2001 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Wed, 21 Nov 2001 16:10:26 -0500 Subject: [PYTHON-CRYPTO] Package name Message-ID: <20011121161026.E16090@ute.mems-exchange.org> While we're changing things around, any thoughts on the package name? Currently it's Crypto.Hash, Crypto.Cipher, &c., but the more common convention seems to be lowercase. So how about crypto.hash, crypto.cipher, ... And does anyone have a suggested interface for registering extensions? There seems no good Pythonic model for doing this sort of thing. --amk From mal at LEMBURG.COM Wed Nov 21 22:12:22 2001 From: mal at LEMBURG.COM (M.-A. Lemburg) Date: Wed, 21 Nov 2001 22:12:22 +0100 Subject: [PYTHON-CRYPTO] Near-term projects for pycrypto References: <20011121175238.19016.qmail@brouhaha.com> <20011121153939.A16090@ute.mems-exchange.org> Message-ID: <3BFC18B6.C66BFA53@lemburg.com> Andrew Kuchling wrote: > > On Wed, Nov 21, 2001 at 05:52:38PM -0000, Paul Rubin wrote: > >3) Supporting the OpenSSL stuff is IMO only worthwhile if the intention > >is to support actual SSL. > > That's a good question; should we concentrate on wrapping OpenSSL or > some other library? If we wrap OpenSSL, , for example, then the > mxCrypto code can be used. Please note that the intention of mxCrypto is to expose the low-level crypto code in OpenSSL -- *not* the SSL implementation on top of it. > Advantages of using a library are: > > * No need to implement the algorithms. > * Someone else can write platform-specific assembly for better performance. > > Disadvantages: > > * the library is one more thing to install. It's available on pretty much every Unix system out there and on Windows and Macs too. > * the modules may get more complicated in order to present a consistent > interface (if the underlying library doesn't support a feedback mode we > do, for example). Depends on how *we* design the interface, right ? I think we can learn a lot from the Python DB API interface -- it chose a very simple, but extendable model. IMHO, all Python standard interfaces should be done this way. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From michael at STROEDER.COM Wed Nov 21 22:06:27 2001 From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Wed, 21 Nov 2001 22:06:27 +0100 Subject: [PYTHON-CRYPTO] Near-term projects for pycrypto References: <20011121175238.19016.qmail@brouhaha.com> <20011121153939.A16090@ute.mems-exchange.org> Message-ID: <3BFC1753.8FFCA9B6@stroeder.com> Andrew Kuchling wrote: > > On Wed, Nov 21, 2001 at 05:52:38PM -0000, Paul Rubin wrote: > >3) Supporting the OpenSSL stuff is IMO only worthwhile if the intention > >is to support actual SSL. > > That's a good question; should we concentrate on wrapping OpenSSL or > some other library? If we wrap OpenSSL, , for example, then the > mxCrypto code can be used. Well, we already had this discussion. Some applications might prefer to only use a small subset of crypto algorithms while other applications are in the need of a full-blown implementation of a cryptographic protocol. Some applications might have difficulties with C extension modules at all, etc. This lead to thinking about drivers for hashes, PRNGs, crypto algorithms and protocols. Remember? Ciao, Michael. From mal at LEMBURG.COM Wed Nov 21 22:16:09 2001 From: mal at LEMBURG.COM (M.-A. Lemburg) Date: Wed, 21 Nov 2001 22:16:09 +0100 Subject: [PYTHON-CRYPTO] Package name References: <20011121161026.E16090@ute.mems-exchange.org> Message-ID: <3BFC1999.4243F334@lemburg.com> Andrew Kuchling wrote: > > While we're changing things around, any thoughts on the package name? > Currently it's Crypto.Hash, Crypto.Cipher, &c., but the more common > convention seems to be lowercase. So how about crypto.hash, > crypto.cipher, ... > > And does anyone have a suggested interface for registering extensions? > There seems no good Pythonic model for doing this sort of thing. Simple: just install the extensions in a well-known directory and then have the API scan that directory for .py[c|o] files. Works great ! Plug&Play sort-of :-) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From michael at STROEDER.COM Wed Nov 21 22:22:49 2001 From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Wed, 21 Nov 2001 22:22:49 +0100 Subject: [PYTHON-CRYPTO] Package name References: <20011121161026.E16090@ute.mems-exchange.org> <3BFC1999.4243F334@lemburg.com> Message-ID: <3BFC1B29.68363F98@stroeder.com> "M.-A. Lemburg" wrote: > > Andrew Kuchling wrote: > > > > And does anyone have a suggested interface for registering extensions? > > There seems no good Pythonic model for doing this sort of thing. > > Simple: just install the extensions in a well-known directory and > then have the API scan that directory for .py[c|o] files. Works > great ! Plug&Play sort-of :-) What to do if two packages A and B are both implementing algorithm c ? Ciao, Michael. From mal at LEMBURG.COM Thu Nov 22 09:52:51 2001 From: mal at LEMBURG.COM (M.-A. Lemburg) Date: Thu, 22 Nov 2001 09:52:51 +0100 Subject: [PYTHON-CRYPTO] Package name References: <20011121161026.E16090@ute.mems-exchange.org> <3BFC1999.4243F334@lemburg.com> <3BFC1B29.68363F98@stroeder.com> Message-ID: <3BFCBCE3.60D89AD3@lemburg.com> Michael Str?der wrote: > > "M.-A. Lemburg" wrote: > > > > Andrew Kuchling wrote: > > > > > > And does anyone have a suggested interface for registering extensions? > > > There seems no good Pythonic model for doing this sort of thing. > > > > Simple: just install the extensions in a well-known directory and > > then have the API scan that directory for .py[c|o] files. Works > > great ! Plug&Play sort-of :-) > > What to do if two packages A and B are both implementing algorithm c > ? There are multiple options: 1. first one found wins 2. raise an exception 3. the registration API of each package defines a preference level and the one with the highest preference value wins (usually the fastest implementation) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From p.mayers at IC.AC.UK Thu Nov 22 13:13:21 2001 From: p.mayers at IC.AC.UK (Mayers, Philip J) Date: Thu, 22 Nov 2001 12:13:21 -0000 Subject: [PYTHON-CRYPTO] Near-term projects for pycrypto Message-ID: In my opinion, OpenSSL. It's very nearly a system default library on most Linux's and free BSDs - OpenSSH requires it, as does mod_ssl, both very common default installs. It builds cleanly on Solaris as well. It's also the most complete, free and Free implementation I know of. Regards, Phil +------------------------------------------+ | Phil Mayers | | Network & Infrastructure Group | | Information & Communication Technologies | | Imperial College | +------------------------------------------+ -----Original Message----- From: Andrew Kuchling [mailto:akuchlin at MEMS-EXCHANGE.ORG] Sent: 21 November 2001 20:40 To: PYTHON-CRYPTO at NIC.SURFNET.NL Subject: Re: [PYTHON-CRYPTO] Near-term projects for pycrypto On Wed, Nov 21, 2001 at 05:52:38PM -0000, Paul Rubin wrote: >3) Supporting the OpenSSL stuff is IMO only worthwhile if the intention >is to support actual SSL. That's a good question; should we concentrate on wrapping OpenSSL or some other library? If we wrap OpenSSL, , for example, then the mxCrypto code can be used. Advantages of using a library are: * No need to implement the algorithms. * Someone else can write platform-specific assembly for better performance. Disadvantages: * the library is one more thing to install. * the modules may get more complicated in order to present a consistent interface (if the underlying library doesn't support a feedback mode we do, for example). --amk From p.mayers at IC.AC.UK Thu Nov 22 20:54:26 2001 From: p.mayers at IC.AC.UK (Mayers, Philip J) Date: Thu, 22 Nov 2001 19:54:26 -0000 Subject: [PYTHON-CRYPTO] Having trouble reading MIT CredCache programatically Message-ID: All, I'm writing a Python kerberos library that's file-compatible with the MIT CredCache, and I'm having a weird time. I can read it into memory fine, but when I decrypt the ticket with the key in that entry, I get nonsense (i.e. no confounder/crc/ticket-in-ASN.1/padding). I'm reading the 8 bytes of the key straight off disk and passing them as the key to a DES-CBC implementation (the amkCrypto one). Here's a test setup for the TEST.COM realm I'm working with: [{'adata': [], 'addrs': [{'address': '\233\3063\023', 'addr_type': 2}], 'client': {'name': {'name_type': 1, 'name_string': ['pjm3']}, 'realm': 'TEST.COM'}, 'flags': 4194304, 'is_skey': '\000', 'key': {'keytype': 1, 'keyvalue': '\031k\031\015\241\33444'}, 'server': {'name': {'name_type': 0, 'name_string': ['krbtgt', 'TEST.COM']}, 'realm': 'TEST.COM'}, 'ticket': {'enc_part': {'cipher': '\014V<\352\016\303\307\363\342\365\354\027\031cm\304\277\351\016`\211\264\2 32T\370\246\00062G\202\307N\004\201\206\373\360s\244AD\007\343\324\224\345\2 45\366\325\305\223\366\367\332X\034\326\3420D\033@\220K\243\264\004\010G\317 \031\367a9\315\014\310\365\342\013\354\022\206\216\200\225\221\265\316\206\2 04\317\035,3\277S\232O\263&U\231\362\254{\315\263F\346\224\017:\227\341{\246 \221.\303c\236\216\241\345s\015rewm\322\256kL1j9\'\031\325\271V\326\032\003\ 317\201\302\307\303', 'etype': 1, 'kvno': 1}, 'realm': 'TEST.COM', 'sname': {'name_string': ['krbtgt', 'TEST.COM'], 'name_type': 0}, 'tkt_vno': 5}, 'times': [1006458564, 1006458564, 1006494564, 0], 'tkt2': ''}] >>> from Crypto import Ciphers >>> d = Ciphers.DES('\031k\031\015\241\33444', Ciphers.CBC) >>> a = '\014V<\352\016\303\307\363\342\365\354\027\031cm\304\277\351\016`\211\264\2 32T\370\246\00062G\202\307N\004\201\206\373\360s\244AD\007\343\324\224\345\2 45\366\325\305\223\366\367\332X\034\326\3420D\033@\220K\243\264\004\010G\317 \031\367a9\315\014\310\365\342\013\354\022\206\216\200\225\221\265\316\206\2 04\317\035,3\277S\232O\263&U\231\362\254{\315\263F\346\224\017:\227\341{\246 \221.\303c\236\216\241\345s\015rewm\322\256kL1j9\'\031\325\271V\326\032\003\ 317\201\302\307\303' >>> b = d.decrypt(a) >>> b '\364\276\254\275\205\013\232\325v\317\373c1\326\375\317~\314\333\000\014\30 1O\025=\026in\316|Y\327\370\323\3210\341\234q?\\\251\003pB\177\364H\027\365\ 007\276\005\374\265\206{U\214g\335\263\021\351hB\012\007\373\331x\335\371\27 43<\343:\226\'\367\206ILcFA\370\223oC\214\033x\323?8\222\254\007W\360\305\33 3Y\003\250P\306\340\005\034\265:\267"~\356c\026\235[\325\266\002\334\311\213 L\355\267\377dS\272\345\320\252\024AZ\032\240\305\361p\265\316\227\203\266B' I would expect b to be an ASN.1-encoded ticket at this point. The password for this principal is "test.com", by the way. I'm obviously doing something basically wrong. Anyone tell me what? Regards, Phil +------------------------------------------+ | Phil Mayers | | Network & Infrastructure Group | | Information & Communication Technologies | | Imperial College | +------------------------------------------+ From phr-pycrypt at nightsong.com Thu Nov 22 21:08:53 2001 From: phr-pycrypt at nightsong.com (Paul Rubin) Date: Thu, 22 Nov 2001 20:08:53 -0000 Subject: [PYTHON-CRYPTO] Near-term projects for pycrypto Message-ID: <20011122200853.733.qmail@brouhaha.com> I don't think it's good to make pycrypto depend on OpenSSL. OpenSSL is a huge cumbersome package that's not pre-installed on THAT many systems. Pycrypto is the most useful if it can be a simple extension module that can be included easily with Python. Most of the complexity in OpenSSL comes from supporting dozens of obscure ciphers that pycrypto doesn't need, and from dealing with X509 certificates and the whole ASN.1 machinery needed to support the certificate system in full generality, CA tools, etc. Having python wrappers for all those functions to enable writing full-blown SSL applications in Python is a fine idea, but if pycrypto doesn't aim to do that, it shouldn't need OpenSSL. Proposed functions for Pycrypto: - AES and 3DES ciphers, plus maybe CAST and RC4. - MD5, SHA, SHA256, and SHA512 hash functions - DH and ECDH key exchange. KEA authenticated key exchange(?). - DSA and/or ECDSA digital signature algorithms. - DH and ECDH-based (El Gamal) public key encryption - Possibly: RSA public key encryption and signatures - Possibly: SRP password authentication (http://srp.stanford.edu) - Yarrow-like PRNG All this stuff put together is about 1/100th the complexity of OpenSSL. Someone suggested a Python JCA wrapper making it possible to call JCA service providers from Jython. That's a nice idea in its own right, but like OpenSSL, it seems outside the scope of pycrypto. Finally, the public key functions should have a way to use GMP or gmpy for the bignum arithmetic, but also to use Python arithmetic if GMP isn't installed. GMP's arithmetic is about 10x faster than Python's. From p.mayers at IC.AC.UK Thu Nov 22 21:52:14 2001 From: p.mayers at IC.AC.UK (Mayers, Philip J) Date: Thu, 22 Nov 2001 20:52:14 -0000 Subject: [PYTHON-CRYPTO] Having trouble reading MIT CredCache programatically Message-ID: Ignore that - the ticket is, of course, encrypted in the service long-term key, not the session key (which is what gets read out of the credcache). How embarassing... Cheers, Phil -----Original Message----- From: Mayers, Philip J To: 'kerberos at MIT.EDU'; PYTHON-CRYPTO at NIC.SURFNET.NL Sent: 22/11/2001 19:54 Subject: Having trouble reading MIT CredCache programatically All, I'm writing a Python kerberos library that's file-compatible with the MIT CredCache, and I'm having a weird time. I can read it into memory fine, but when I decrypt the ticket with the key in that entry, I get nonsense (i.e. no confounder/crc/ticket-in-ASN.1/padding). From sholden at HOLDENWEB.COM Sat Nov 24 20:41:13 2001 From: sholden at HOLDENWEB.COM (Steve Holden) Date: Sat, 24 Nov 2001 14:41:13 -0500 Subject: [PYTHON-CRYPTO] Near-term projects for pycrypto References: <20011122200853.733.qmail@brouhaha.com> Message-ID: <002301c1751f$faa77900$0200000a@holdenweb.com> ----- Original Message ----- From: "Paul Rubin" To: Sent: Thursday, November 22, 2001 3:08 PM Subject: Re: Near-term projects for pycrypto > I don't think it's good to make pycrypto depend on OpenSSL. OpenSSL > is a huge cumbersome package that's not pre-installed on THAT many > systems. Pycrypto is the most useful if it can be a simple extension > module that can be included easily with Python. Most of the > complexity in OpenSSL comes from supporting dozens of obscure ciphers > that pycrypto doesn't need, and from dealing with X509 certificates > and the whole ASN.1 machinery needed to support the certificate system > in full generality, CA tools, etc. > Speaking as a lurker who got involved with Python crypto because I needed to *use* it, having had to implement amk/mxCrypto was a monumental PITA. It's not that the software isn't good, just that the build isn't automated. I'm lucky enough to have the experience to overcome (most of) the hurdles, but the build complexity of amkCrypto certainly limits the user base. Building SSL was just yet another unnecessary and unwanted step :-) > Having python wrappers for all those functions to enable writing > full-blown SSL applications in Python is a fine idea, but if pycrypto > doesn't aim to do that, it shouldn't need OpenSSL. > Whether Pycrypto wants to be this I don't know, but there is certainly a crying need for an easy-to-install, easy-to-use crypto package, with performance as a secondary issue. If there were a harder-to-install, higher-performance substitute package this would be a bonus. > Proposed functions for Pycrypto: > - AES and 3DES ciphers, plus maybe CAST and RC4. > - MD5, SHA, SHA256, and SHA512 hash functions > - DH and ECDH key exchange. KEA authenticated key exchange(?). > - DSA and/or ECDSA digital signature algorithms. > - DH and ECDH-based (El Gamal) public key encryption > - Possibly: RSA public key encryption and signatures > - Possibly: SRP password authentication (http://srp.stanford.edu) > - Yarrow-like PRNG > > All this stuff put together is about 1/100th the complexity of OpenSSL. > > Someone suggested a Python JCA wrapper making it possible to call JCA > service providers from Jython. That's a nice idea in its own right, > but like OpenSSL, it seems outside the scope of pycrypto. > > Finally, the public key functions should have a way to use GMP or gmpy > for the bignum arithmetic, but also to use Python arithmetic if GMP > isn't installed. GMP's arithmetic is about 10x faster than Python's. > Sounds like a good idea, and I believe your suggested package content would meet a high percentage of crypto requirements (though I installed amkCrypto because I needed Blowfish). regards Steve -- http://www.holdenweb.com/ From itamarst at YAHOO.COM Sun Nov 25 00:09:55 2001 From: itamarst at YAHOO.COM (Itamar S.-T.) Date: Sat, 24 Nov 2001 15:09:55 -0800 Subject: [PYTHON-CRYPTO] Near-term projects for pycrypto In-Reply-To: <002301c1751f$faa77900$0200000a@holdenweb.com> Message-ID: <20011124230955.96834.qmail@web13007.mail.yahoo.com> --- Steve Holden wrote: > Building SSL was just yet another unnecessary and > unwanted step :-) I disagree. It is a pain, yes, but mostly it's a pain on Windows. And for windows you just need to make an installable .exe, and only once, and users will happily use this. I've no doubt building Python on Windows is a pain too, but users never have to deal with this themselves. Of course, there's the question if OpenSSL works on Macintosh and other less popular platforms. ===== Itamar Shtull-Trauring, itamar(at)shtull-trauring.org __________________________________________________ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1 From p.mayers at IC.AC.UK Sat Nov 24 19:31:39 2001 From: p.mayers at IC.AC.UK (Mayers, Philip J) Date: Sat, 24 Nov 2001 18:31:39 -0000 Subject: [PYTHON-CRYPTO] Having trouble reading MIT CredCache programatically Message-ID: As my follow up indicated (which of course you read), I do realise that a client doesn't have the service key - I wasn't thinking when I typed the mail and it was a stupid question. I could give many flippant, impolite answers to your first question, but instead I'll say: Why not? Are you so sure that the MIT or Heimdal implementations are so perfect that there's nothing I can contribute by making a third interoperable one? If so, I envy your confidence. Regards, Phil +------------------------------------------+ | Phil Mayers | | Network & Infrastructure Group | | Information & Communication Technologies | | Imperial College | +------------------------------------------+ -----Original Message----- From: Sam Hartman [mailto:hartmans at MIT.EDU] Sent: 23 November 2001 23:03 To: Mayers, Philip J Cc: 'kerberos at MIT.EDU'; PYTHON-CRYPTO at NIC.SURFNET.NL Subject: Re: Having trouble reading MIT CredCache programatically >>>>> "Mayers," == Mayers, Philip J writes: Mayers,> All, I'm writing a Python kerberos library that's Mayers,> file-compatible with the MIT CredCache, and I'm having a Mayers,> weird time. Why do you do this thing? Aren't there enough implementations of Kerberos out there? Do you really want to keep up with all the crypto system changes in Kerberos or upcoming ccache changes to support ticket extensions? Also, you are aware that the client generally never has the service key necessary to decrypt the ticket, right? From michael at STROEDER.COM Sun Nov 25 19:08:09 2001 From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Sun, 25 Nov 2001 19:08:09 +0100 Subject: [PYTHON-CRYPTO] Package name References: <20011121161026.E16090@ute.mems-exchange.org> <3BFC1999.4243F334@lemburg.com> <3BFC1B29.68363F98@stroeder.com> <3BFCBCE3.60D89AD3@lemburg.com> Message-ID: <3C013389.845C4D2E@stroeder.com> "M.-A. Lemburg" wrote: > > Michael Str?der wrote: > > > > "M.-A. Lemburg" wrote: > > > > > > Andrew Kuchling wrote: > > > > > > Simple: just install the extensions in a well-known directory and > > > then have the API scan that directory for .py[c|o] files. Works > > > great ! Plug&Play sort-of :-) > > > > What to do if two packages A and B are both implementing algorithm c > > ? > > There are multiple options: > 1. first one found wins Very bad. > 2. raise an exception Also makes no sense to me. > 3. the registration API of each package defines a preference > level and the one with the highest preference value wins (usually > the fastest implementation) How to maintain a preference level? Who is going to maintain the preference level? How to value preference (e.g. speed vs. security)? I'm more in favour of a deterministic configuration scheme. Ciao, Michael. From michael at STROEDER.COM Sun Nov 25 19:04:25 2001 From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Sun, 25 Nov 2001 19:04:25 +0100 Subject: [PYTHON-CRYPTO] Near-term projects for pycrypto References: <20011124230955.96834.qmail@web13007.mail.yahoo.com> Message-ID: <3C0132A9.241EEBEA@stroeder.com> "Itamar S.-T." wrote: > > --- Steve Holden wrote: > > > Building SSL was just yet another unnecessary and > > unwanted step :-) > > I disagree. > > It is a pain, yes, but mostly it's a pain on Windows. > And for windows you just need to make an installable > .exe, and only once, and users will happily use this. There's no doubt that it's overkill and code bloat having to build the complete OpenSSL package if one just needs e.g. a single hash algorithm or symmetric cipher. Ciao, Michael. From mal at LEMBURG.COM Mon Nov 26 11:21:06 2001 From: mal at LEMBURG.COM (M.-A. Lemburg) Date: Mon, 26 Nov 2001 11:21:06 +0100 Subject: [PYTHON-CRYPTO] Package name References: <20011121161026.E16090@ute.mems-exchange.org> <3BFC1999.4243F334@lemburg.com> <3BFC1B29.68363F98@stroeder.com> <3BFCBCE3.60D89AD3@lemburg.com> <3C013389.845C4D2E@stroeder.com> Message-ID: <3C021792.D3C474D4@lemburg.com> > [Auto-Configuration of Crypto Drivers] > > > > > Simple: just install the extensions in a well-known directory and > > > > then have the API scan that directory for .py[c|o] files. Works > > > > great ! Plug&Play sort-of :-) > > > > > > What to do if two packages A and B are both implementing algorithm c > > > ? > > > > There are multiple options: > > 1. first one found wins > > Very bad. That's the way Python imports have always worked -- can't be that bad ;-) This is also, what the codec lookup mechanism implements. > > 2. raise an exception > > Also makes no sense to me. Why not ? That way the user will know that there's a problem and that she'll have to fix it according to her own preferences. > > 3. the registration API of each package defines a preference > > level and the one with the highest preference value wins (usually > > the fastest implementation) > > How to maintain a preference level? Who is going to maintain the > preference level? How to value preference (e.g. speed vs. security)? We'd define preference levels for various aspects of the implementation, the driver writer would use these values and provide constants to the auto-registration mechanism and the user would choose by passing the intended levels to the lookup API. > I'm more in favour of a deterministic configuration scheme. An alternative mechanism would be to make imports explicit; the user will then have to explicitly set the driver for the rest of the crypto API to use. This loses the automatic setup aspect, though. Personally, I don't really care, because I'd most probably go with an OpenSSL-based crypto driver (that's what I've done in the past and most probably will do in the future ;-). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From ngps at POST1.COM Mon Nov 26 17:15:22 2001 From: ngps at POST1.COM (Ng Pheng Siong) Date: Tue, 27 Nov 2001 00:15:22 +0800 Subject: [PYTHON-CRYPTO] Package name In-Reply-To: <3C021792.D3C474D4@lemburg.com>; from mal@LEMBURG.COM on Mon, Nov 26, 2001 at 11:21:06AM +0100 References: <20011121161026.E16090@ute.mems-exchange.org> <3BFC1999.4243F334@lemburg.com> <3BFC1B29.68363F98@stroeder.com> <3BFCBCE3.60D89AD3@lemburg.com> <3C013389.845C4D2E@stroeder.com> <3C021792.D3C474D4@lemburg.com> Message-ID: <20011127001522.A783@madcap.dyndns.org> On Mon, Nov 26, 2001 at 11:21:06AM +0100, M.-A. Lemburg wrote: > Personally, I don't really care, because I'd most probably > go with an OpenSSL-based crypto driver (that's what I've done > in the past and most probably will do in the future ;-). +1 here. All this talk about drivers, abstract package naming, etc., appears to me to be an effort to reinvent the Java crypto framework for Python. Personally, I'm not interested in that. I'm interested in building applications that use crypto. Ok, for certain applications, maybe I need to build _some_ foundation, but this will be higher-level stuff, say, XML-dsig or shared RSA key generation. Hashes and ciphers? Just pick some existing implementations and go already! To all those who are awaiting a standardised Python crypto API before you begin coding your crypto applications, please, just do it. -- Ng Pheng Siong * http://www.post1.com/home/ngps From p.mayers at IC.AC.UK Wed Nov 28 13:17:00 2001 From: p.mayers at IC.AC.UK (Mayers, Philip J) Date: Wed, 28 Nov 2001 12:17:00 -0000 Subject: [PYTHON-CRYPTO] Having trouble reading MIT CredCache programatically Message-ID: Ah, OK. I could have misunderstood... I'm afraid I no longer code in C if I can possibly avoid it. Also, I'm rather an advocate of certain programming techniques which are an anathema to the vast majority of C-based Unix projects, so any contributions I could make are likely to be summarily rejected ("Here is a patch to make all strings in MIT Kerberos be STL ropes...", and such like :o) I realise the file format is not meant to be interoperable. The specific reason I'm doing this is I want to play with PKINIT and would still like to use all my usual apps with the ticket I get, which means using a different kinit program to populate my cred cache. There are other reasons (it's interesting, fun, teaches me a lot, and so on). I wouldn't worry. It's highly likely that I'll never get to a release, since I can't seem to figure the des-cbc-crc enctype out... Regards, Phil +------------------------------------------+ | Phil Mayers | | Network & Infrastructure Group | | Information & Communication Technologies | | Imperial College | +------------------------------------------+ -----Original Message----- From: Booker C. Bense [mailto:bbense at networking.stanford.edu] Sent: 27 November 2001 21:15 To: 'kerberos at MIT.EDU' Cc: PYTHON-CRYPTO at NIC.SURFNET.NL Subject: RE: Having trouble reading MIT CredCache programatically On Sat, 24 Nov 2001, Mayers, Philip J wrote: > As my follow up indicated (which of course you read), I do realise that a > client doesn't have the service key - I wasn't thinking when I typed the > mail and it was a stupid question. > > I could give many flippant, impolite answers to your first question, but > instead I'll say: Why not? Are you so sure that the MIT or Heimdal > implementations are so perfect that there's nothing I can contribute by > making a third interoperable one? If so, I envy your confidence. > - I think what Sam was trying to tell you was that your code won't be interoperable. The file ccache format that MIT is currently using is not meant to be a "public" format and can be changed at any time. In fact it will be changed in the near future. You're supposed to use the API to access it. I think Sam is well aware of the flaws of kerberos and wishes people that had time to work on it would work on fixing the existing code, rather than redoing all the same old errors in a different code. - You may not be familiar with the history of kerberos, but it is rife with just slightly incompatible API's that have put up huge roadblocks to interoperablity and code exchange in the past. Of course that never stopped anybody before and I don't expect it to now. - Booker C. Bense From eggsy at gmx.de Wed Nov 28 09:26:25 2001 From: eggsy at gmx.de (Eric Johnson) Date: Wed, 28 Nov 2001 03:26:25 -0500 Subject: [PYTHON-CRYPTO] Near-term projects for pycrypto In-Reply-To: <20011121175238.19016.qmail@brouhaha.com>; from phr-pycrypt@NIGHTSONG.COM on Wed, Nov 21, 2001 at 05:52:38PM -0000 Message-ID: <20011128032625.A1280@Erdos.GDAI.COM\000> Sorry for the lateness of this reply (the server kept bouncing my submission) but I don't think we have resolved this issue yet. On Wed, Nov 21, 2001 at 05:52:38PM -0000, Paul Rubin wrote: > 6) The above is from the philosophical standpoint that Pycrypt is > mainly supposed to give app writers a way to put crypto into their > applications without being crypto experts. The alternate view it's > more intended as a toolkit for experts. Either view is ok with me, > but the designers should make a clear decision about what the goals > are, rather than muddling around between various possible goals. > I agree with this and think that we need to define what the goals of Pycrypt are. My personal requirements are to have a low level cryptographic library which is easily extendible to use new algorithms and which can be used to generate test data for * debugging and testing assembler implementations * statistical purposes (eg for DPA type attacks) * educational and experimental purposes I would prefer to have a pure Python implementation for ease of modification. I realise that these are esoteric requirements but I would like to think that we could come up with a framework that would meet these and other peoples' requirements. Whilst, I think one goal should be to allow crypto to be used in Python apps by non-experts is desireable, we should not handicap the system by reducing the flexibility and prohibiting certain algorithms or modes of operation. Doing this will just give false confidence to novices -- most crypto failures are at the system level rather than weak algorithms. The following are on my wish-list for PyCrypt 1) It must use distutils for distribution purposes 2) It must have a pure Python implmentation with optional C extensions for those who need the performance 3) It should have a high-level API for novices and a low-level API for more sophisticated users. 4) It should be possible to select the algorithms and modes of operation using factory methods (so that it is as simple as possible to replace an algorithm or change the mode of operation) 5) It should be easy to implement a new mode of operation or algorithm and have it fit naturally into the framework - this should be the case for pure Python implementations and for C extensions. For example, if we do use openssl then it should still be possible for me to implement a C extension without having to modify openssl or wait for openssl to support this algorithm. I think that we should concentrate on symmetric algorithms to start with. The framework should be much simpler and less controversial than public key. Further down the road it would be nice to add some features that are not so common such as secret sharing or generating domain parameters for Elliptic Curve systems. Eric Johnson