diff options
Diffstat (limited to 'pipermail/pycrypto/attachments/20081108/0da0db16/attachment-0001.htm')
| -rw-r--r-- | pipermail/pycrypto/attachments/20081108/0da0db16/attachment-0001.htm | 84 |
1 files changed, 84 insertions, 0 deletions
diff --git a/pipermail/pycrypto/attachments/20081108/0da0db16/attachment-0001.htm b/pipermail/pycrypto/attachments/20081108/0da0db16/attachment-0001.htm new file mode 100644 index 0000000..e4d1e8e --- /dev/null +++ b/pipermail/pycrypto/attachments/20081108/0da0db16/attachment-0001.htm @@ -0,0 +1,84 @@ +<tt> +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><br> +<HTML><HEAD><br> +<META http-equiv=Content-Type content=text/html;charset=iso-8859-1><br> +<STYLE></STYLE><br> +<br> +<META content="MSHTML 6.00.6000.16735" name=GENERATOR></HEAD><br> +<BODY id=MailContainerBody <br> +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" <br> +leftMargin=0 topMargin=0 acc_role="text" CanvasTabStop="true" <br> +name="Compose message area"><!--[gte IE 5]><?xml:namespace prefix="v" /><?xml:namespace prefix="o" /><![endif]--><br> +<DIV><br> +<DIV>Dear Python Cryptographers,</DIV><br> +<DIV>&nbsp;</DIV><br> +<DIV>this is an urgent call for help and the an attempt to convince all <br> +participants of the imperative to reconstruct pycrypto from the get-go.</DIV><br> +<DIV>&nbsp;</DIV><br> +<DIV>To start with the good points of Kuchling's library:</DIV><br> +<DIV>&nbsp;</DIV><br> +<DIV>With respect to the files block_template.c, hash_template.c and <br> +stream_template.c one has to state that the Kuchling library has solid <br> +fundation. In my eyes the C code is of high quality. Well structured, readable <br> +and reusable. Kuchling was avoding C header files, which reduces the amount of <br> +files significantly and is very good to keep the overview.</DIV><br> +<DIV>Furtheron the possibility to add new (not contained) algorithms is <br> +impressive, even if I guess that it's not a such trivial job to add one like <br> +this is stated in the documentation.</DIV><br> +<DIV>&nbsp;</DIV><br> +<DIV>The weak side of Kuchling's library is resulting mainly&nbsp;from the <br> +choice of offered algorithms:</DIV><br> +<OL><br> + <LI>Hash algorithm<BR>Meantimes the&nbsp;main part of the offered hash <br> + algorithms is classified as "weak" or "wounded" by the cryptographic community <br> + (see <A title=about:blank <br> + href="">http://www.cryptolounge.org/wiki/Category:Algorithm</A>). With respect <br> + to the recommendations of the NIST and others I propose to offer the following <br> + algorithm additionally and directly over the distributed library interface: <br> + SHA-224, SHA-256 (C file is allready included), SHA-384, SHA-512, RIPEMD-128, <br> + RIPEMD-160, RIPEMD-256, RIPEMD-320, Tiger and WHIRLPOOL. In my eyes this <br> + abundance of offered hash algorithms is necessary since hash algorithms are <br> + attacked frequently. <br> + <LI>Block ciphers<BR>Well the choice of block ciphers looks like the US style <br> + of life: The winner takes it all! A serious cryptographic library has to offer <br> + all five AES finalists (Mars, RC6, Rijndael, Serpent and Twofish). There is no <br> + doubt, that each finalist is a great cipher. This five ciphers are the best <br> + block ciphers, which the public cryptographic community is offering to the <br> + world. <br> + <LI>Stream ciphers<BR>The choice of offered stream ciphers appears to me like <br> + a bad joke. ARC4 is classified as "weak" by the cryptographic community and <br> + this incredible offer of XOR - don't know what to say for this (one could read <br> + in the bible [Schneier, Applied Cryptography, second edition] on page 198 how <br> + it break it; well, Kuchling has red the bible, but never the less he is <br> + offering this XOR). In fact at this time pycrypt is not offering any stream <br> + cipher that could be used seriously. What a mess!<BR>I propose the direct <br> + offering of the following stream ciphers (mainly candidates of the eSTREAM <br> + project <A title=about:blank href="">http://www.ecrypt.eu.org/stream/</A>): <br> + HC-128, HC-256, Panama (could be used as hash algorithm but as hash algorithm <br> + and only as hash algorithm it is classified as "wounded"), Rabbit (if you want <br> + to strike algorithms form my list, then this one frist, because it's patented <br> + and so only nocommerical use is free), Salsa20, SOSEMANUK and Phelix (this one <br> + is made by Schneier &amp; co., on the eSTREAM project was published an attack <br> + against Phelix and in result it was classified as "wounded", but the attack is <br> + only working if one uses the "nonce == number used once" (parameter to realize <br> + the integrated MAC) more then once. So I think that Phelix is appraised <br> + unfair). <br> + <LI>Random generator<BR>Sorry Dwanye, I disagree with you. A cryptographic <br> + library has to offer a cryptographic secure random generator. Without that the <br> + library is not useful at all. <br> + <LI>Asymmetric algorithms<BR>Like stated in Dwanye's wishlist Diffie-Hellman <br> + support would be nice.</LI></OL><br> +<DIV>To fill the wide algorithmic gap of pycrypt I propose a look at Crypto++ <br> +Library of Wei Dai (<A title=about:blank href="">http://www.cryptopp.com</A>). <br> +Crypto++ is licensed like pycrypt and recommanded by the NIST. In this C++ <br> +library could be found all to fill the gap. But this library has a damned ugly <br> +structur and contains more than 333 file. So it will be a lot of work to extract <br> +the useful things.</DIV><br> +<DIV>&nbsp;</DIV><br> +<DIV>Let's talk serious Dwanyne! Will you update your wishlist?</DIV><br> +<DIV>&nbsp;</DIV><br> +<DIV>Stefan</DIV><br> +<DIV>&nbsp;</DIV><br> +<DIV>&nbsp;</DIV></DIV></BODY></HTML><br> + +</tt> |