[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()
> >>> pk.publickey() != pk.publickey()
> (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
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
I don't quite understand the security impact of this (if any), but it was
= = = = = = = = = = = = = =
Here are some quick links:
PyCrypto 2.1.0 release announcement:
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
Size: 221 bytes
Desc: Digital signature
Url : http://lists.dlitz.net/pipermail/pycrypto/attachments/20091215/65d1618a/attachment.pgp
More information about the pycrypto