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

Thorsten Behrens sbehrens at gmx.li
Sun Jan 2 14:16:40 CST 2011

On 1/2/2011 11:06 AM, Paul Hoffman wrote:

> 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.
No kidding. I am having a hard time just understanding what is needed to 
get them
right, never mind attempting to code things in a secure manner.

> 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.
I think I will pass on that. That is more aggressive than I think I have 
any standing to be.
I am already changing quite a few things with the Py3k port. I'd like to 
leave my commit
at that - Py3k compatibility, additional unit tests for a couple things, 
documentation - and then sit down with the all of you to think long and 
hard about
the kind of API interface that a "pycrypto-next" should offer, and how 
to bind it to
known-good libraries.

> My personal feeling is pycrypto should *not* offer its own
> implementation of crypto algorithms. [Good justification as to why] If someone is going to do
> this, I would prefer Crypto++ to NSS just because of the bindings
Could you elaborate on that comment regarding bindings, please? I am
dreaming about crypto APIs now (this may be a sign, of what I am
not sure :/), and any additional input as to what constitutes a good one
is very welcome.

I happen to be strongly biased towards Crypto++, btw - it's comprehensive,
it looks to receive a lot of attention on secure implementation, and
it's public domain.
I also like the idea of having a design that is flexible enough to support
multiple libraries, with a separate translation layer/shim each, chosen
at build time. That way, pycrypto doesn't bind itself too closely to any
one implementation, and it gives people choice, though that choice may
be theoretical at first - say if no one feels motivated enough to write an
NSS shim. Still the option would be there. Choice is good.



More information about the pycrypto mailing list