Sun Apr 12 08:35:41 CST 2009
knows how to deal with performance trade-offs, and do not need to be patronized.
Note that we should also define what "too slow" means, 2x? 20x? 50x? What
would be an acceptable slow-down, provided that we know that by the time
performance has become a problem, the *advanced* user would have already
switched to an optimized library/wrapper?
For instance, the Actionscript crypto library as3crypto is completely written
and one positive performance report:
Note the remark "since most of this is client side and only one user would be
using it this is not an issue - server side is where this can have scale problems
from parallel execution but flash is rarely server side if it is too slow,
but it is quite fast".
> It would also double the cost
> of maintenance of the library. But a pure python implementation would be
> convenient for verification of correctness and for documentation
Correct, so the cost doesn't double actually. :-)
> (Note: I don't understand your comments about being scriptable and a
> command-line crypto workbench. That seems to be features related to
> using Python, independent of which crypto library you use.)
I don't use often pycrpto for full-blown applications. Instead, I make several
small proof-of-concepts prototypes that help in setting up the final (C-based!)
crypto module of the real application.
More information about the pycrypto