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

[Lorenz Quack]

Hi

On 12/31/2010 03:58 PM, Thorsten Behrens wrote:
>[...]
> What I have found is that pycrypto's Elgamal implementation is, shall we say, naive. Specifically in these regards
> (and I'll quote others here, these assertions as per crypto safety are not mine. The conclusions about elgamal.py are
> mine):
>
> /- p/  SHOULD be a safe prime, i.e. such that (/p/-1)/2 is prime
>
> TB: elgamal.py makes no effort to find a safe prime. elgamal.py does not allow the user to pass her own safe prime to
> the key generator.

Just for the record: a "safe prime" is *not* the same thing as a "strong prime". A strong prime is a prime p where p-1 
and p+1 have large prime factors. strong primes are used in RSA and safe primes for discrete logarithm based techniques. 
pycrypto has a function for generating "strong primes" (getStrongPrime()) but not for safe primes.
I know that nobody claimed otherwise but I wanted to mention it because I was stumped for a moment because of the 
similarity of the names.

> [...]
> The broader question that occurs, particularly also in view of the stdlib-crypto discussion
> (http://bugs.python.org/issue8998) is: What is pycrypto's intent? What should it be?

Wow! I was not aware that there is an ongoing stdlib-crypto discussion. Thanks a lot!

> Should it be a low-level collection of crypto algorithms, suitable for academic and real work, and requiring a strong
> understanding of crypto and its complexities in either case, with no safeguards should a user choose to shoot himself
> in the foot?
>
> Should it be a high-level collection of crypto routines, suitable for the crypto-naive coder, offering safe defaults
> and a few knobs to influence those parameters that should be able to be chosen by a slightly less crypto-naive coder?
> Note that this would require vigorous debate about what this second tier should look like, which defaults would be
> chosen, which knobs would still be exposed, and so on. That debate would have to be carried out in public and would
> have to include all the other movers-and-shakers in the Python crypto community.
>
> Should it be both, offering a two-tiered API?
>
> And further:
>
> 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?
>
>
> Thank you for reading
>
> Thorsten

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.
2) The API was more pythonic than many libraries that only wrap the calls to C-functions of underlying libraries.

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.
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.
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.
Feel free to disagree :)

Enough ranting for today.

Cheers and thanks a lot to all the people that built, improve and maintain this great piece of software.
Sincerely yours,
Lorenz

[1] http://tahoe-lafs.org/trac/pycryptopp
[2] http://people.redhat.com/jdennis/python-nss/doc/api/html/
[3] http://buggywhip.blogspot.com/2007/06/python-ctypes-wrapper-for-libtomcrypt.html