[pycrypto] Comments on Elgamal, and a broader question: Whither pycrypto?

[Paul Hoffman]

On Fri, Dec 31, 2010 at 6:58 AM, Thorsten Behrens <sbehrens at gmx.li> wrote:
> I've been looking into writing a unit test for Elgamal. What I was looking
> for were public test vectors. Those don't exist. What I found instead is
> that our implementation of Elgamal appears insecure.

No surprise there. I suspect if you look closely at all the primitives
that require good computation of keys and/or fresh randoms, you will
find more problems just because these things are hard to get right.

> So far on Elgamal. It makes me reluctant to go through with a unit test for
> Elgamal. I don't want to validate an implementation that is inherently
> insecure. Changing Elgamal to be more secure is out of scope of my current
> effort on the code base. I'll leave that to others.

Given that you suspect (with good evidence) that it is insecure, you
should instead strongly consider commenting out all the code and links
to it, with a notation why of course.

> Should pycrypto continue to offer its own implementations of crypto
> algorithms? Or should it be a Python wrapper for existing implementations
> such as tomlib, Crypto++ or NSS, relying on those implementations to have
> been coded in a secure manner?

My personal feeling is pycrypto should *not* offer its own
implementation of crypto algorithms. The need for a pure-Python crypto
library is probably small but real, but so is the need for that
library to be secure. You have shown that the latter need is not being
met. Instead, I think that a good, really Pythonic interface to a
known-good library has a much higher value. If someone is going to do
this, I would prefer Crypto++ to NSS just because of the bindings, but
either would be useful, and certainly more useful than a crypto
library without sufficient checking.

--Paul Hoffman