From mal at EGENIX.COM Tue Dec 1 11:55:28 2009 From: mal at EGENIX.COM (M.-A. Lemburg) Date: Tue, 1 Dec 2009 11:55:28 +0100 Subject: [PYTHON-CRYPTO] Crypto code on PyPI Message-ID: <4B14F620.9080509@egenix.com> Some time ago we discussed the possibility and implications of uploading crypto code to PyPI. I had asked the PSF board for their view on this. Below is the reply I received yesterday. The two paragraphs Martin is talking about can be found on the web-site at http://www.python.org/about/legal/: """ Third-Party Content The Python Software Foundation (?PSF?) does not claim ownership of any third-party code or content (?third party content?) placed on the web site and has no obligation of any kind with respect to such third party content. Any third party content provided in connection with this web site is provided on a non-confidential basis. The PSF is free to use or disseminate such content on an unrestricted basis for any purpose, and third party content providers grant the PSF and all other users of the web site an irrevocable, worldwide, royalty-free, nonexclusive license to reproduce, distribute, transmit, display, perform, and publish such content, including in digital form. Third party content providers represent and warrant that they have obtained the proper governmental authorizations for the export and reexport of any software or other content contributed to this web site by the third-party content provider, and further affirm that any United States-sourced cryptographic software is not intended for use by a foreign government end-user. Individuals and organizations subject to United States law are advised that this website is hosted in the Netherlands, and uploading packages to PyPI containing United States-sourced cryptographic software is strictly forbidden without compliance with United States export controls under the Export Administration Regulations. """ In summary, it's up to the uploader of crypto code to deal with the export regulations based on the fact that the python.org servers are located in the Netherlands. This could mean that the uploader has to fulfill extra notification requirements (e.g. if uploading from the US) or other regulations imposed by the country of origin. Note that in addition to the US export rules, crypto code may not be intended for foreign government end-users (see second paragraph above). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 01 2009) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ -------- Original Message -------- Subject: Re: [PSF-Board] Crypto code on PyPI Date: Mon, 30 Nov 2009 17:04:10 +0100 From: "Martin v. L?wis" To: M.-A. Lemburg CC: Python Board > What's the PSF's point of view on this ? We have now implemented our lawyers' advice on this matter, which led to the inclusion of two paragraphs into http://www.python.org/about/legal/ Van Lindberg writes: """ The PSF hosts a web site (PyPI) located in the Netherlands to which programmers are able to upload software modules that work with Python, which is a publicly available programming language. Some of these uploaded software modules may contain encryption components of varying algorithms and key-lengths, including those in excess of 56-bits. In this regard, PyPI acts as a search engine or directory for code contributed by other individuals; the contents of individual packages on PyPI are not created, owned, or uploaded by the PSF itself or anyone acting as an agent of the PSF. Some of the package download links point to packages on PSF-hosted servers; others point to servers outside the control of the PSF. The contents of packages downloaded from PyPI may be downloaded interactively (by a person) or by an automated software agent (such as easy_install). With reference to PyPI, the export of encryption source or object code is actually performed by the person uploading the package to PyPI, and not by the PSF itself. This export takes place when a package containing United States-sourced encryption is uploaded to the PyPI server in the Netherlands. The individual or entity that uploads U.S.-origin encryption software is responsible for obtaining the necessary U.S. government classification and licensing prior to the software being uploaded to the PSF web site. """ Regards, Martin From boober95 at ROGERS.COM Thu Dec 10 07:40:25 2009 From: boober95 at ROGERS.COM (Bill) Date: Thu, 10 Dec 2009 01:40:25 -0500 Subject: [PYTHON-CRYPTO] Problems building M2Crypto on CentOS running x86_64 Message-ID: <200912100140.26069.boober95@rogers.com> I am unable to build M2Crypto 0.19 or 0.20 on CentOS 5 running x86_64. I have not problems building running the same system in 32 bit, but 64 fails. The error suggest recompiling with the -fPIC option, but this has me baffled. Has anyone managed to build it in 64 bit and if so could you reveal the secret (BTW, I tried Ubuntu 8.05 and64 with the same results). /bill From heikki at OSAFOUNDATION.ORG Thu Dec 10 07:58:29 2009 From: heikki at OSAFOUNDATION.ORG (Heikki Toivonen) Date: Wed, 9 Dec 2009 22:58:29 -0800 Subject: [PYTHON-CRYPTO] Problems building M2Crypto on CentOS running x86_64 In-Reply-To: <200912100140.26069.boober95@rogers.com> References: <200912100140.26069.boober95@rogers.com> Message-ID: <4B209C15.9020005@osafoundation.org> Bill wrote: > I am unable to build M2Crypto 0.19 or 0.20 on CentOS 5 running x86_64. I have > not problems building running the same system in 32 bit, but 64 fails. The > error suggest recompiling with the -fPIC option, but this has me baffled. > > Has anyone managed to build it in 64 bit and if so could you reveal the secret > (BTW, I tried Ubuntu 8.05 and64 with the same results). I personally build without problems on Ubuntu 8.04 32 and 64 bit, and Redhat has provided Tinderbox build slaves that also regularly build 64 bit versions on RH 5.x Are you using the the fedora_setup.sh script? Are you sure your OpenSSL version is supported (note that openssl 1.0 series is not yet supported although there is a nearly complete patch)? -- Heikki Toivonen - http://heikkitoivonen.net From boober95 at ROGERS.COM Thu Dec 10 08:41:11 2009 From: boober95 at ROGERS.COM (Bill) Date: Thu, 10 Dec 2009 02:41:11 -0500 Subject: [PYTHON-CRYPTO] Problems building M2Crypto on CentOS running x86_64 In-Reply-To: <200912100140.26069.boober95@rogers.com> References: <200912100140.26069.boober95@rogers.com> Message-ID: <200912100241.11981.boober95@rogers.com> Doing a bit more investigation, I see M2Crypto 0.19 is build on Fedora 11 x86_64 against OpenSSL 0.9.8, but I don't see how they did it there? /bill On Thursday 10 December 2009 01:40, you wrote: > I am unable to build M2Crypto 0.19 or 0.20 on CentOS 5 running x86_64. I > have not problems building running the same system in 32 bit, but 64 fails. > The error suggest recompiling with the -fPIC option, but this has me > baffled. > > Has anyone managed to build it in 64 bit and if so could you reveal the > secret (BTW, I tried Ubuntu 8.05 and64 with the same results). > > /bill From boober95 at ROGERS.COM Thu Dec 10 17:55:35 2009 From: boober95 at ROGERS.COM (Bill) Date: Thu, 10 Dec 2009 11:55:35 -0500 Subject: [PYTHON-CRYPTO] Problems building M2Crypto on CentOS running x86_64 In-Reply-To: <4B209C15.9020005@osafoundation.org> References: <200912100140.26069.boober95@rogers.com> <4B209C15.9020005@osafoundation.org> Message-ID: <200912101155.35695.boober95@rogers.com> Thanks for the quick reply, I am really stumped. I see Fedora 11 has an m2crypto 64 bit build, so I know it can be done, but I haven't been able. Here is some more exact version info and what I have done to build: OpenSSL 0.9.8j, M2Crypto 0.19.1, Python 2.5.2, CentOS 5.3 The build command I am using is, and which is failing is: python2.5 setup.py build build_ext --openssl=/usr/local/ssl The error is near the end of the build (the link) and is: gcc -pthread -shared build/temp.linux-x86_64-2.5/SWIG/_m2crypto_wrap.o -L/usr/local/ssl/lib -lssl -lcrypto -o build/lib.linux-x86_64-2.5/M2Crypto/__m2crypto.so /usr/bin/ld: /usr/local/ssl/lib/libcrypto.a(x86_64cpuid.o): relocation R_X86_64_PC32 against `OPENSSL_cpuid_setup' can not be used when making a shared object; recompile with -fPIC I tried running the fedora script, but I don't have an architecture config file for openssl, just opensslconfig.h. I have build on 32 bit without problem without the script and using the script and the config I have. If you have some idea of what the issue is I'd really appreciate it since I am rapidly running out of options. /bill On Thursday 10 December 2009 01:58, Heikki Toivonen wrote: > Bill wrote: > > I am unable to build M2Crypto 0.19 or 0.20 on CentOS 5 running x86_64. I > > have not problems building running the same system in 32 bit, but 64 > > fails. The error suggest recompiling with the -fPIC option, but this has > > me baffled. > > > > Has anyone managed to build it in 64 bit and if so could you reveal the > > secret (BTW, I tried Ubuntu 8.05 and64 with the same results). > > I personally build without problems on Ubuntu 8.04 32 and 64 bit, and > Redhat has provided Tinderbox build slaves that also regularly build 64 > bit versions on RH 5.x > > Are you using the the fedora_setup.sh script? Are you sure your OpenSSL > version is supported (note that openssl 1.0 series is not yet supported > although there is a nearly complete patch)? From mitr at REDHAT.COM Thu Dec 10 18:01:16 2009 From: mitr at REDHAT.COM (Miloslav Trmac) Date: Thu, 10 Dec 2009 12:01:16 -0500 Subject: [PYTHON-CRYPTO] Problems building M2Crypto on CentOS running x86_64 In-Reply-To: <200912101155.35695.boober95@rogers.com> Message-ID: <1278648291.1536681260464476150.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> Hello, ----- "Bill" wrote: > gcc -pthread -shared build/temp.linux-x86_64-2.5/SWIG/_m2crypto_wrap.o > -L/usr/local/ssl/lib -lssl -lcrypto -o > build/lib.linux-x86_64-2.5/M2Crypto/__m2crypto.so > /usr/bin/ld: /usr/local/ssl/lib/libcrypto.a(x86_64cpuid.o): relocation > R_X86_64_PC32 against `OPENSSL_cpuid_setup' can not be used when making a > shared object; recompile with -fPIC You have a local OpenSSL build that does not contain a shared library. Mirek From boober95 at ROGERS.COM Thu Dec 10 19:44:46 2009 From: boober95 at ROGERS.COM (Bill) Date: Thu, 10 Dec 2009 13:44:46 -0500 Subject: [PYTHON-CRYPTO] Problems building M2Crypto on CentOS running x86_64 In-Reply-To: <1278648291.1536681260464476150.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> References: <1278648291.1536681260464476150.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> Message-ID: <200912101344.46696.boober95@rogers.com> Excellent ... that seems to have solved the last issue I was having. So what I had to do to get it to build was to rebuild OpenSSL after running: ./config shared Then I had to create a library path in /etc/ls.so.conf.d and run /sbin/ldconfig. Now I can build it and import it. When I run the tests I get a lot of errors 'EEEEE ...' and then it segfaults. I compared this to the Fedora 11 build and it also gets the errors, but doesn't segfault, it just hangs. Anyhow it is a start and hopefully the functions I need are working. /bill PS: To keep SELinux running I had to add the following command: chcon -t textrel_shlib_t /usr/local/lib/python2.5/site-packages/M2Crypto/__m2crypto.so On Thursday 10 December 2009 12:01, Miloslav Trmac wrote: > Hello, > > ----- "Bill" wrote: > > gcc -pthread -shared build/temp.linux-x86_64-2.5/SWIG/_m2crypto_wrap.o > > -L/usr/local/ssl/lib -lssl -lcrypto -o > > build/lib.linux-x86_64-2.5/M2Crypto/__m2crypto.so > > /usr/bin/ld: /usr/local/ssl/lib/libcrypto.a(x86_64cpuid.o): relocation > > R_X86_64_PC32 against `OPENSSL_cpuid_setup' can not be used when making a > > shared object; recompile with -fPIC > > You have a local OpenSSL build that does not contain a shared library. > Mirek From dlitz at DLITZ.NET Sun Dec 13 21:59:34 2009 From: dlitz at DLITZ.NET (Dwayne C. Litzenberger) Date: Sun, 13 Dec 2009 15:59:34 -0500 Subject: [PYTHON-CRYPTO] ANN: PyCrypto 2.1.0 released! Message-ID: <20091213205934.GA11878@rivest.dlitz.net> PyCrypto 2.1.0 has been released. This is the first stable release since I took over as maintainer of PyCrypto. It is compatible with Python 2.1 through 2.6. (Python 3.x is not yet supported.) You can download this release from http://www.pycrypto.org/ It has the following SHA256 sums: 253e1c22ea0249f0429df4f7e2eb973b119c83b146c0f421298f5e8e6822d8a2 *pycrypto-2.1.0.tar.gz ed296d283e367a47b5fb8ed17309bd3e67a1e712caae519fb0bbff5ad0723eda *pycrypto-2.1.0.tar.gz.asc Please test it and post your experiences to the PyCrypto mailing list: pycrypto at lists.dlitz.net and/or file bug reports on Launchpad: https://bugs.launchpad.net/pycrypto Here is a (non-exhaustive) list of changes between 2.0.1 and 2.1.0: 2.1.0 ===== * Fix building PyCrypto on Win64 using MS Visual Studio 9. (Thanks: Nevins Bartolomeo.) 2.1.0beta1 ========== * Modified RSA.generate() to ensure that e is coprime to p-1 and q-1. Apparently, RSA.generate was capable of generating unusable keys. 2.1.0alpha2 =========== * Modified isPrime() to release the global interpreter lock while performing computations. (patch from Lorenz Quack) * Release the GIL while encrypting, decrypting, and hashing (but not during initialization or finalization). * API changes: - Removed RandomPoolCompat and made Crypto.Util.randpool.RandomPool a wrapper around Crypto.Random that emits a DeprecationWarning. This is to discourage developers from attempting to provide backwards compatibility for systems where there are NO strong entropy sources available. - Added Crypto.Random.get_random_bytes(). This should allow people to use something like this if they want backwards-compatibility: try: from Crypto.Random import get_random_bytes except ImportError: try: from os import urandom as get_random_bytes except ImportError: get_random_bytes = open("/dev/urandom", "rb").read - Implemented __ne__() on pubkey, which fixes the following broken behaviour: >>> pk.publickey() == pk.publickey() True >>> pk.publickey() != pk.publickey() True (patch from Lorenz Quack) - Block ciphers created with MODE_CTR can now operate on strings of any size, rather than just multiples of the underlying cipher's block size. - Crypto.Util.Counter objects now raise OverflowError when they wrap around to zero. You can override this new behaviour by passing allow_wraparound=True to Counter.new() 2.1.0alpha1 =========== * This version supports Python versions 2.1 through 2.6. * Clarified copyright status of much of the existing code by tracking down Andrew M. Kuchling, Barry A. Warsaw, Jeethu Rao, Joris Bontje, Mark Moraes, Paul Swartz, Robey Pointer, and Wim Lewis and getting their permission to clarify the license/public-domain status of their contributions. Many thanks to all involved! * Replaced the test suite with a new, comprehensive package (Crypto.SelfTest) that includes documentation about where its test vectors came from, or how they were derived. Use "python setup.py test" to run the tests after building. * API changes: - Added Crypto.version_info, which from now on will contain version information in a format similar to Python's sys.version_info. - Added a new random numbers API (Crypto.Random), and deprecated the old one (Crypto.Util.randpool.RandomPool), which was misused more often than not. The new API is used by invoking Crypto.Random.new() and then just reading from the file-like object that is returned. CAVEAT: To maintain the security of the PRNG, you must call Crypto.Random.atfork() in both the parent and the child processes whenever you use os.fork(). Otherwise, the parent and child will share copies of the same entropy pool, causing them to return the same results! This is a limitation of Python, which does not provide readily-accessible hooks to os.fork(). It's also a limitation caused by the failure of operating systems to provide sufficiently fast, trustworthy sources of cryptographically-strong random numbers. - Crypto.PublicKey now raises ValueError/TypeError/RuntimeError instead of the various custom "error" exceptions - Removed the IDEA and RC5 modules due to software patents. Debian has been doing this for a while - Added Crypto.Random.random, a strong version of the standard Python 'random' module. - Added Crypto.Util.Counter, providing fast counter implementations for use with CTR-mode ciphers. * Bug fixes: - Fixed padding bug in SHA256; this resulted in bad digests whenever (the number of bytes hashed) mod 64 == 55. - Fixed a 32-bit limitation on the length of messages the SHA256 module could hash. - AllOrNothing: Fixed padding bug in digest() - Fixed a bad behaviour of the XOR cipher module: It would silently truncate all keys to 32 bytes. Now it raises ValueError when the key is too long. - DSA: Added code to enforce FIPS 186-2 requirements on the size of the prime p - Fixed the winrandom module, which had been omitted from the build process, causing security problems for programs that misuse RandomPool. - Fixed infinite loop when attempting to generate RSA keys with an odd number of bits in the modulus. (Not that you should do that.) * Clarified the documentation for Crypto.Util.number.getRandomNumber. Confusingly, this function does NOT return N random bits; It returns a random N-bit number, i.e. a random number between 2**(N-1) and (2**N)-1. Note that getRandomNumber is for internal use only and may be renamed or removed in future releases. * Replaced RIPEMD.c with a new implementation (RIPEMD160.c) to alleviate copyright concerns. * Replaced the DES/DES3 modules with ones based on libtomcrypt-1.16 to alleviate copyright concerns. * Replaced Blowfish.c with a new implementation to alleviate copyright concerns. * Added a string-XOR implementation written in C (Crypto.Util.strxor) and used it to speed up Crypto.Hash.HMAC * Converted documentation to reStructured Text. * Added epydoc configuration Doc/epydoc-config * setup.py now emits a warning when building without GMP. * Added pct-speedtest.py to the source tree for doing performance testing on the new code. * Cleaned up the code in several places. Thanks to everyone who helped make this release possible! Cheers, - Dwayne -- Dwayne C. Litzenberger Key-signing key - 19E1 1FE8 B3CF F273 ED17 4A24 928C EC13 39C2 5CF7 Annual key (2009) - C805 1746 397B 0202 2758 2821 58E0 894B 81D2 582E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 221 bytes Desc: Digital signature URL: From dlitz at DLITZ.NET Tue Dec 15 06:47:35 2009 From: dlitz at DLITZ.NET (Dwayne C. Litzenberger) Date: Tue, 15 Dec 2009 00:47:35 -0500 Subject: [PYTHON-CRYPTO] Wanted: PyCrypto security advisories In-Reply-To: <20091213205934.GA11878@rivest.dlitz.net> References: <20091213205934.GA11878@rivest.dlitz.net> Message-ID: <20091215054735.GA32625@rivest.dlitz.net> On Sun, Dec 13, 2009 at 03:59:34PM -0500, Dwayne C. Litzenberger wrote: > PyCrypto 2.1.0 has been released. This release of PyCrypto fixes a number of issues, but the previous release, version 2.0.1 is still widely deployed. I'm a terrible maintainer with too many half-baked projects on the go. It would be great if someone familiar with making security advisories went through this release, acquired CVE numbers where appropriate, and issued security advisories for bugs in PyCrypto 2.0.1 and in software that uses it incorrectly. I'm an advocate of full disclosure, so if you find any additional problems that haven't been fixed yet, please just file a bug on Launchpad and make whatever other announcements you deem necessary. I don't think I have some inherent right to know about exploitable vulnerabilities in other people's computers before they do, just because I happen to be (badly) maintaining some software they use. (Please also consider supporting http://wikileaks.org/.) Here are some highlights from the changelog, with my comments: > - Implemented __ne__() on pubkey, which fixes the following > broken behaviour: > >>> pk.publickey() == pk.publickey() > True > >>> pk.publickey() != pk.publickey() > True > (patch from Lorenz Quack) This isn't a security hole in PyCrypto, but I wonder if other software breaks, due to PyCrypto violating the expectations of application developers. > - Fixed padding bug in SHA256; this resulted in bad digests > whenever (the number of bytes hashed) mod 64 == 55. I think some distros (e.g. Debian) had this fixed already. At minimum, this is a compatibility problem. Maybe it's also a security hole; I'm not a cryptanalyst, so I don't know. > - Fixed a bad behaviour of the XOR cipher module: It would > silently truncate all keys to 32 bytes. Now it raises ValueError > when the key is too long. Code that used Crypto.Cipher.XOR to XOR two long strings together would fail silently. If your code raises a ValueError here after upgrading to PyCrypto 2.1.0, then you have a security hole. > - Fixed the winrandom module, which had been omitted from the > build process, causing security problems for programs that misuse > RandomPool. In the code I've seen, misusing RandomPool is almost universal. Someone can probably generate a bunch of advisories just by searching Google Code Search for "RandomPool". See https://bugs.launchpad.net/pycrypto/+bug/249765, and follow the links. > * Modified RSA.generate() to ensure that e is coprime to p-1 and > q-1. Apparently, RSA.generate was capable of generating unusable > keys. I don't quite understand the security impact of this (if any), but it was reported here: https://bugs.launchpad.net/pycrypto/+bug/408660 = = = = = = = = = = = = = = Here are some quick links: PyCrypto 2.1.0 release announcement: http://lists.dlitz.net/pipermail/pycrypto/2009q4/000169.html Bug tracker: https://bugs.launchpad.net/pycrypto Website: http://www.pycrypto.org/ git repo: git://git.pycrypto.org:9419/crypto/pycrypto-2.x.git gitweb: http://gitweb.pycrypto.org/?p=crypto/pycrypto-2.x.git Cheers, - Dwayne -- Dwayne C. Litzenberger Key-signing key - 19E1 1FE8 B3CF F273 ED17 4A24 928C EC13 39C2 5CF7 Annual key (2009) - C805 1746 397B 0202 2758 2821 58E0 894B 81D2 582E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 221 bytes Desc: Digital signature URL: