<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content=text/html;charset=iso-8859-1>
<STYLE></STYLE>
<META content="MSHTML 6.00.6000.16735" name=GENERATOR></HEAD>
<BODY id=MailContainerBody
style="PADDING-LEFT: 10px; FONT-WEIGHT: normal; FONT-SIZE: 10pt; COLOR: #000000; BORDER-TOP-STYLE: none; PADDING-TOP: 15px; FONT-STYLE: normal; FONT-FAMILY: Verdana; BORDER-RIGHT-STYLE: none; BORDER-LEFT-STYLE: none; BORDER-BOTTOM-STYLE: none"
leftMargin=0 topMargin=0 acc_role="text" CanvasTabStop="true"
name="Compose message area"><!--[gte IE 5]><?xml:namespace prefix="v" /><?xml:namespace prefix="o" /><![endif]-->
<DIV>
<DIV>Dear Python Cryptographers,</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>To start with the good points of Kuchling's library:</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>The weak side of Kuchling's library is resulting mainly from the
choice of offered algorithms:</DIV>
<OL>
<LI>Hash algorithm<BR>Meantimes the main part of the offered hash
algorithms is classified as "weak" or "wounded" by the cryptographic community
(see <A title=about:blank
href="">http://www.cryptolounge.org/wiki/Category:Algorithm</A>). 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.
<LI>Block ciphers<BR>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.
<LI>Stream ciphers<BR>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!<BR>I propose the direct
offering of the following stream ciphers (mainly candidates of the eSTREAM
project <A title=about:blank href="">http://www.ecrypt.eu.org/stream/</A>):
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).
<LI>Random generator<BR>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.
<LI>Asymmetric algorithms<BR>Like stated in Dwanye's wishlist Diffie-Hellman
support would be nice.</LI></OL>
<DIV>To fill the wide algorithmic gap of pycrypt I propose a look at Crypto++
Library of Wei Dai (<A title=about:blank href="">http://www.cryptopp.com</A>).
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.</DIV>
<DIV> </DIV>
<DIV>Let's talk serious Dwanyne! Will you update your wishlist?</DIV>
<DIV> </DIV>
<DIV>Stefan</DIV>
<DIV> </DIV>
<DIV> </DIV></DIV></BODY></HTML>