[pycrypto] Wanted: PyCrypto security advisories

Dwayne C. Litzenberger dlitz at dlitz.net
Mon Dec 14 23:47:35 CST 2009

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 

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 

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 

> 	  - 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:


= = = = = = = = = = = = = =

Here are some quick links:

PyCrypto 2.1.0 release announcement:
Bug tracker:
git repo:

- Dwayne

Dwayne C. Litzenberger <dlitz at dlitz.net>
  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: not available
Type: application/pgp-signature
Size: 221 bytes
Desc: Digital signature
Url : http://lists.dlitz.net/pipermail/pycrypto/attachments/20091215/65d1618a/attachment.pgp 

More information about the pycrypto mailing list