1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE> [pycrypto] the sad state of pycrypto
</TITLE>
<LINK REL="Index" HREF="index.html" >
<LINK REL="made" HREF="mailto:pycrypto%40lists.dlitz.net?Subject=%5Bpycrypto%5D%20the%20sad%20state%20of%20pycrypto&In-Reply-To=BAY105-DS6DE1AA2CEEFC3406A72CAAA180%40phx.gbl">
<META NAME="robots" CONTENT="index,nofollow">
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<LINK REL="Previous" HREF="000038.html">
<LINK REL="Next" HREF="000040.html">
</HEAD>
<BODY BGCOLOR="#ffffff">
<H1>[pycrypto] the sad state of pycrypto</H1>
<B>Dwayne C. Litzenberger</B>
<A HREF="mailto:pycrypto%40lists.dlitz.net?Subject=%5Bpycrypto%5D%20the%20sad%20state%20of%20pycrypto&In-Reply-To=BAY105-DS6DE1AA2CEEFC3406A72CAAA180%40phx.gbl"
TITLE="[pycrypto] the sad state of pycrypto">dlitz at dlitz.net
</A><BR>
<I>Sun Nov 9 09:34:10 CST 2008</I>
<P><UL>
<LI>Previous message: <A HREF="000038.html">[pycrypto] the sad state of pycrypto
</A></li>
<LI>Next message: <A HREF="000040.html">[pycrypto] the sad state of pycrypto
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#39">[ date ]</a>
<a href="thread.html#39">[ thread ]</a>
<a href="subject.html#39">[ subject ]</a>
<a href="author.html#39">[ author ]</a>
</LI>
</UL>
<HR>
<!--beginarticle-->
<PRE>On Sat, Nov 08, 2008 at 04:18:51PM -0430, Stefan Spoettl wrote:
><i>Dear Python Cryptographers,
</I>><i>
</I>><i>this is an urgent call for help and the an attempt to convince all
</I>><i>participants of the imperative to reconstruct pycrypto from the get-go.
</I>
I agree that PyCrypto needs an overhaul, but I do not consider it "urgent",
and rushing would be counter-productive.
><i>To start with the good points of Kuchling's library:
</I>><i>
</I>><i>With respect to the files block_template.c, hash_template.c and
</I>><i>stream_template.c one has to state that the Kuchling library has solid
</I>><i>fundation. In my eyes the C code is of high quality. Well structured,
</I>><i>readable and reusable. Kuchling was avoding C header files, which reduces
</I>><i>the amount of files significantly and is very good to keep the overview.
</I>><i>
</I>><i>Furtheron the possibility to add new (not contained) algorithms is
</I>><i>impressive, even if I guess that it's not a such trivial job to add one
</I>><i>like this is stated in the documentation.
</I>
Yeah, it's a nice architecture. Unfortunately, it also requires that
algorithms be hand-written in (error-prone) C, so I want to keep the amount
of C code in PyCrypto to a minimum.
Cryptography is a waste of time if an attacker can make your program run
arbitrary code, thanks to a buffer overflow or other subtle bug. I am
hesitant to add new algorithms to PyCrypto until they can be developed in a
more trustworthy fashion.
(I'm toying with the idea of a restricted subset of C that requires all
arrays to be of size 2**n, and requires the appropriate bit-wise AND
whenever indexing the array. However, an implementation is a long way off.
I'm also interested in languages like D and BitC, but I'm not sure about
the maturity of their compilers. I could use help here.)
My thoughts mirror the ideas presented in D. J. Bernstein's paper, "Some
thoughts on security after ten years of qmail 1.0"
<<A HREF="http://cr.yp.to/qmail/qmailsec-20071101.pdf">http://cr.yp.to/qmail/qmailsec-20071101.pdf</A>>. I encourage everyone here
to read it, if you have not already.
><i>The weak side of Kuchling's library is resulting mainly from the choice of offered algorithms:
</I>><i> 1.. Hash algorithm
</I>><i> Meantimes the main part of the offered hash algorithms is classified as
</I>><i> "weak" or "wounded" by the cryptographic community (see
</I>><i> <A HREF="http://www.cryptolounge.org/wiki/Category:Algorithm<about:blank">http://www.cryptolounge.org/wiki/Category:Algorithm<about:blank</A>>).
</I>
Which algorithms are you referring to? Just MD2? I'm willing to drop MD2
if there are no objections. I'm not going to be removing MD5 or SHA-1 any
time soon; They're just wrappers around the Python standard library anyway.
><i> With respect to the recommendations of the NIST and others I propose to
</I>><i> offer the following algorithm additionally and directly over the
</I>><i> distributed library interface: SHA-224, SHA-256 (C file is allready
</I>><i> included), SHA-384, SHA-512, RIPEMD-128, RIPEMD-160, RIPEMD-256,
</I>><i> RIPEMD-320, Tiger and WHIRLPOOL.
</I>
My understanding is that SHA-224 and SHA-384 are encumbered by software
patents and provide no performance advantages over SHA-256 and SHA-512,
respectively.
PyCrypto already has RIPEMD-160. PyCrypto does not have RIPEMD-128, but
it's a hash function with a 128-bit output, which means it only provides
2**64 security against a birthday attack. In other words, it's obsolete.
RIPEMD-256 and RIPEMD-320 provide no better security than RIPEMD-160*.
Therefore, they are redundant, and can only serve to mislead users into
thinking that they provide additional security.
(* See <A HREF="http://homes.esat.kuleuven.be/~bosselae/ripemd160.html">http://homes.esat.kuleuven.be/~bosselae/ripemd160.html</A>)
><i> In my eyes this abundance of offered hash algorithms is necessary since
</I>><i> hash algorithms are attacked frequently.
</I>
Out of the options on your list, only SHA-512, Tiger and WHIRLPOOL interest
me. I would consider them for inclusion at some later date, but see my
concerns above regarding adding lots of new C code.
><i> 2.. Block ciphers
</I>><i> Well the choice of block ciphers looks like the US style of life: The
</I>><i> winner takes it all! A serious cryptographic library has to offer all
</I>><i> five AES finalists (Mars, RC6, Rijndael, Serpent and Twofish). There is
</I>><i> no doubt, that each finalist is a great cipher. This five ciphers are
</I>><i> the best block ciphers, which the public cryptographic community is
</I>><i> offering to the world.
</I>
Again, a "serious cryprographic library" has to avoid implementation bugs
above all else. Otherwise, it is just wasting CPU cycles and giving people
a false sense of security.
><i> 3.. Stream ciphers
</I>><i> The choice of offered stream ciphers appears to me like a bad joke. ARC4
</I>><i> is classified as "weak" by the cryptographic community and this
</I>><i> incredible offer of XOR - don't know what to say for this (one could
</I>><i> read in the bible [Schneier, Applied Cryptography, second edition] on
</I>><i> page 198 how it break it; well, Kuchling has red the bible, but never
</I>><i> the less he is offering this XOR). In fact at this time pycrypt is not
</I>><i> offering any stream cipher that could be used seriously. What a mess!
</I>
I will drop the XOR module. It should be unnecessary now that we have
Crypto.Util.strxor for speeding up things like HMAC.
><i> I propose the direct offering of the following stream ciphers (mainly
</I>><i> candidates of the eSTREAM project
</I>><i> <A HREF="http://www.ecrypt.eu.org/stream/<about:blank">http://www.ecrypt.eu.org/stream/<about:blank</A>>): HC-128, HC-256, Panama
</I>><i> (could be used as hash algorithm but as hash algorithm and only as hash
</I>><i> algorithm it is classified as "wounded"), Rabbit (if you want to strike
</I>><i> algorithms form my list, then this one frist, because it's patented and
</I>><i> so only nocommerical use is free), Salsa20, SOSEMANUK and Phelix (this
</I>><i> one is made by Schneier & co., on the eSTREAM project was published an
</I>><i> attack against Phelix and in result it was classified as "wounded", but
</I>><i> the attack is only working if one uses the "nonce == number used once"
</I>><i> (parameter to realize the integrated MAC) more then once. So I think
</I>><i> that Phelix is appraised unfair).
</I>
What's the rush to add new stream ciphers? Stream ciphers are still
largely experimental, and using a block cipher in CTR mode works well
enough in cases where you need arbitrary-length ciphertexts.
Also, patent-encumbered algorithms are a non-starter. Accordingly, I will
be removing IDEA and RC5 before the next release.
><i> 4.. Random generator
</I>><i> Sorry Dwanye, I disagree with you. A cryptographic library has to offer
</I>><i> a cryptographic secure random generator. Without that the library is not
</I>><i> useful at all
</I>
Please avoid the hyperbole. PyCrypto is quite useful, even if it does not
provide its own RNG, especially since Python itself provides os.urandom()
since version 2.5. Having said that, PyCrypto already has a CSPRNG. See
my other email.
><i> 5.. Asymmetric algorithms
</I>><i> Like stated in Dwanye's wishlist Diffie-Hellman support would be nice.
</I>
Have you noticed that the RSA module does not do any padding, and the DSA
module does not do the necessary hashing?
PyCrypto still has many "gotchas" like that. My current priority is to
take steps to reduce implementation bugs in PyCrypto and in code that uses
PyCrypto. Adding many new algorithms right now will not further that goal.
><i>To fill the wide algorithmic gap of pycrypt I propose a look at Crypto++
</I>><i>Library of Wei Dai (<A HREF="http://www.cryptopp.com">http://www.cryptopp.com</A>). Crypto++ is licensed like
</I>><i>pycrypt and recommanded by the NIST. In this C++ library could be found
</I>><i>all to fill the gap. But this library has a damned ugly structur and
</I>><i>contains more than 333 file. So it will be a lot of work to extract the
</I>><i>useful things.
</I>
At this point, I care far more about implementation quality than about the
number of available algorithms. If you think you need lots of new
algorithms in your project, then nothing prevents you from using both
PyCrypto and Zooko's pycryptopp project:
<A HREF="http://allmydata.org/trac/pycryptopp">http://allmydata.org/trac/pycryptopp</A>
I see no reason to duplicate Zooko's work.
I want to make PyCrypto into a good, reliable, usable crypto library, and I
need lots of criticism and feedback to make that happen. Thanks for your
input. :-)
--
Dwayne C. Litzenberger <<A HREF="http://lists.dlitz.net/cgi-bin/mailman/listinfo/pycrypto">dlitz at dlitz.net</A>>
Key-signing key - 19E1 1FE8 B3CF F273 ED17 4A24 928C EC13 39C2 5CF7
Annual key (2008) - 4B2A FD82 FC7D 9E38 38D9 179F 1C11 B877 E780 4B45
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : <A HREF="http://lists.dlitz.net/pipermail/pycrypto/attachments/20081109/ef808002/attachment-0001.pgp">http://lists.dlitz.net/pipermail/pycrypto/attachments/20081109/ef808002/attachment-0001.pgp</A>
</PRE>
<!--endarticle-->
<HR>
<P><UL>
<!--threads-->
<LI>Previous message: <A HREF="000038.html">[pycrypto] the sad state of pycrypto
</A></li>
<LI>Next message: <A HREF="000040.html">[pycrypto] the sad state of pycrypto
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#39">[ date ]</a>
<a href="thread.html#39">[ thread ]</a>
<a href="subject.html#39">[ subject ]</a>
<a href="author.html#39">[ author ]</a>
</LI>
</UL>
<hr>
<a href="http://lists.dlitz.net/cgi-bin/mailman/listinfo/pycrypto">More information about the pycrypto
mailing list</a><br>
</body></html>
|
