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
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE> [pycrypto] Library design philosophy
</TITLE>
<LINK REL="Index" HREF="index.html" >
<LINK REL="made" HREF="mailto:pycrypto%40lists.dlitz.net?Subject=%5Bpycrypto%5D%20Library%20design%20philosophy&In-Reply-To=49E29FB2.6060805%40echeque.com">
<META NAME="robots" CONTENT="index,nofollow">
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<LINK REL="Previous" HREF="000086.html">
<LINK REL="Next" HREF="000088.html">
</HEAD>
<BODY BGCOLOR="#ffffff">
<H1>[pycrypto] Library design philosophy</H1>
<B>Legrandin</B>
<A HREF="mailto:pycrypto%40lists.dlitz.net?Subject=%5Bpycrypto%5D%20Library%20design%20philosophy&In-Reply-To=49E29FB2.6060805%40echeque.com"
TITLE="[pycrypto] Library design philosophy">gooksankoo at hoiptorrow.mailexpire.com
</A><BR>
<I>Mon Apr 13 04:46:52 CST 2009</I>
<P><UL>
<LI>Previous message: <A HREF="000086.html">[pycrypto] Library design philosophy
</A></li>
<LI>Next message: <A HREF="000088.html">[pycrypto] Library design philosophy
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#87">[ date ]</a>
<a href="thread.html#87">[ thread ]</a>
<a href="subject.html#87">[ subject ]</a>
<a href="author.html#87">[ author ]</a>
</LI>
</UL>
<HR>
<!--beginarticle-->
<PRE>><i> Doing crypto in pure python is evil. No one should ever do it, and any
</I>><i> package that does it is wrong.
</I>
Statements like "Doing xxx is evil" are evil. :-)
It is only a matter of context. You probably have the bulk data processing
in mind, in which case I agree that using pure python is a bad design choice.
Other contexts you may want to consider are the following:
- getting optimized crypto is tricky AND platform dependent. Regression tests
in C are a pain to write. Having them in python offers a quicker path to bug fixing.
- producing test vectors for protocols is a pain in C, and straightforward
in python
- algorithms used for key exchange are typically used only once in a while
on the client side and they are not the best candidates for optimization
- it is faster to introduce a new crypto routine or extend an existing one
in python than in C. This is essential for prototyping, which is a field
python excel in.
Moreover two facts that I see overlooked are that portable C does not exist,
and out there we have plenty of different device/compiler combinations that
will interpret in different ways your well-thought source code. Maybe the
python runtime you are relying on was built with special tricks, and in order
to compile your library you have to re-invent te wheel once again.
JIT compilers are also on the rise for python, and when they get mature, the
performance gap will be consistently reduced. Not a reason for not having the
most common crypto blocks in optimized C, like DES, AES, SHA-1. But I also
think that one should not have to install an optional library to use DES, AES,
SHA-1: the standard one should provide them straightaway.
Cheers,
Legrandin
</PRE>
<!--endarticle-->
<HR>
<P><UL>
<!--threads-->
<LI>Previous message: <A HREF="000086.html">[pycrypto] Library design philosophy
</A></li>
<LI>Next message: <A HREF="000088.html">[pycrypto] Library design philosophy
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#87">[ date ]</a>
<a href="thread.html#87">[ thread ]</a>
<a href="subject.html#87">[ subject ]</a>
<a href="author.html#87">[ 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>
|
