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

[Thorsten Behrens]

On 1/2/2011 4:49 PM, Lorenz Quack wrote:
>
> Just for the record: a "safe prime" is *not* the same thing as a "strong prime". [...]
> pycrypto has a function for generating "strong primes" (getStrongPrime()) but not for safe primes.
Correct. Also, elgamal.py doesn't call the function for strong primes. 
Much less safe primes, since we don't have one of those :)

> Wow! I was not aware that there is an ongoing stdlib-crypto discussion. Thanks a lot!
Of course. Martin v. Loewis asked the participants there: Absent user 
input, what do the experts think? And by "experts",
he explicitly referred to the pycrypto maintainers. That's you guys. I 
think it makes a lot of sense to plug you into
the discussion.

> Here are my 2 cents:
> When I was looking for a python crypto package I chose pycrypto mainly for two reasons.
> 1) It had the fewest dependencies. Only the optionally (though highly recommended) libgmp.
Okay, I get that. A pycrypto-next that wraps existing libraries would 
break that. This is something to weigh against the (very real) 
difficulty of writing and maintaining a body of secure crypto routines.

Hybrid models are possible. We could snag low-level crypto primitives as 
source from Crypto++ and tomlib, and wrap "pythonic" things around those.

> 2) The API was more pythonic than many libraries that only wrap the calls to C-functions of underlying libraries.
Absolutely, that's a great strength. I'd like to see that extended to a 
stronger API for public key crypto, message padding and secure key 
generation.

> Some people say that pycrypto should not implement the crypto primitives but rather us existing libraries. While I do
> understand the rationale behind such a statement, I have to voice my opposition. AFAIK there are already python bindings
> for virtually every major crypto library [1-3]. The only issue with those libraries might be the API but I would suggest
> that one first tries to persuade the maintainers to adopt a more PEP 272 like API.
Okay, that's a really good point. You make the point, if I understand 
you right, that pycrypto does not need to be what others already are, 
and there's something to be said for having less dependencies.

How, then, do we go about offering secure implementations of crypto 
primitives, however?

> Instead I would suggest to slim down pycrypto. Support one or two of each: block cipher, public key crypto, Hash
> function. Try to harden their implementation and then move to provide a good upper layer which takes care of padding,
> envelope encryption and so on.
I see. So, make an effort to provide the most pertinent algorithms. Do 
not provide everything-under-the-Sun. Leave existing stuff in for 
backwards compatibility. Then, once that is done, provide an additional 
layer that helps people to implement it correctly - without ever 
becoming KeyCzar. KeyCzar already exists, after all, and it depends on 
pycrypto.

> This way pycrypto will be a slim independent library which gets the job done. If someone really needs block cipher XYZ
> then kindly point them to a more exhaustive package that wraps an underlying crypto library.
I get your point.
> Feel free to disagree :)
I'm just stirring the pot. It's Dwayne and you guys who make this 
decision. I'm the new guy on the block who comes in with a certain 
amount of fresh enthusiasm and questions the status quo.

All the best
Thorsten