[pycrypto] the sad state of pycrypto

[Stefan Spoettl]

Dear Python Cryptographers,

this is an urgent call for help and the an attempt to convince all participants of the imperative to reconstruct pycrypto from the get-go.

To start with the good points of Kuchling's library:

With respect to the files block_template.c, hash_template.c and stream_template.c one has to state that the Kuchling library has solid fundation. In my eyes the C code is of high quality. Well structured, readable and reusable. Kuchling was avoding C header files, which reduces the amount of files significantly and is very good to keep the overview.
Furtheron the possibility to add new (not contained) algorithms is impressive, even if I guess that it's not a such trivial job to add one like this is stated in the documentation.

The weak side of Kuchling's library is resulting mainly from the choice of offered algorithms:
  1.. Hash algorithm
  Meantimes the main part of the offered hash algorithms is classified as "weak" or "wounded" by the cryptographic community (see http://www.cryptolounge.org/wiki/Category:Algorithm<about:blank>). With respect to the recommendations of the NIST and others I propose to offer the following algorithm additionally and directly over the distributed library interface: SHA-224, SHA-256 (C file is allready included), SHA-384, SHA-512, RIPEMD-128, RIPEMD-160, RIPEMD-256, RIPEMD-320, Tiger and WHIRLPOOL. In my eyes this abundance of offered hash algorithms is necessary since hash algorithms are attacked frequently. 
  2.. Block ciphers
  Well the choice of block ciphers looks like the US style of life: The winner takes it all! A serious cryptographic library has to offer all five AES finalists (Mars, RC6, Rijndael, Serpent and Twofish). There is no doubt, that each finalist is a great cipher. This five ciphers are the best block ciphers, which the public cryptographic community is offering to the world. 
  3.. Stream ciphers
  The choice of offered stream ciphers appears to me like a bad joke. ARC4 is classified as "weak" by the cryptographic community and this incredible offer of XOR - don't know what to say for this (one could read in the bible [Schneier, Applied Cryptography, second edition] on page 198 how it break it; well, Kuchling has red the bible, but never the less he is offering this XOR). In fact at this time pycrypt is not offering any stream cipher that could be used seriously. What a mess!
  I propose the direct offering of the following stream ciphers (mainly candidates of the eSTREAM project http://www.ecrypt.eu.org/stream/<about:blank>): HC-128, HC-256, Panama (could be used as hash algorithm but as hash algorithm and only as hash algorithm it is classified as "wounded"), Rabbit (if you want to strike algorithms form my list, then this one frist, because it's patented and so only nocommerical use is free), Salsa20, SOSEMANUK and Phelix (this one is made by Schneier & co., on the eSTREAM project was published an attack against Phelix and in result it was classified as "wounded", but the attack is only working if one uses the "nonce == number used once" (parameter to realize the integrated MAC) more then once. So I think that Phelix is appraised unfair). 
  4.. Random generator
  Sorry Dwanye, I disagree with you. A cryptographic library has to offer a cryptographic secure random generator. Without that the library is not useful at all. 
  5.. Asymmetric algorithms
  Like stated in Dwanye's wishlist Diffie-Hellman support would be nice.
To fill the wide algorithmic gap of pycrypt I propose a look at Crypto++ Library of Wei Dai (http://www.cryptopp.com<about:blank>). Crypto++ is licensed like pycrypt and recommanded by the NIST. In this C++ library could be found all to fill the gap. But this library has a damned ugly structur and contains more than 333 file. So it will be a lot of work to extract the useful things.

Let's talk serious Dwanyne! Will you update your wishlist?

Stefan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.dlitz.net/pipermail/pycrypto/attachments/20081108/0da0db16/attachment.htm