[pycrypto] Library design philosophy
gooksankoo at hoiptorrow.mailexpire.com
Mon Apr 13 04:46:52 CST 2009
> Doing crypto in pure python is evil. No one should ever do it, and any
> package that does it is wrong.
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
- 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.
More information about the pycrypto