[pycrypto] Library design philosophy

[Legrandin]

> 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
  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