No subject

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
in AS:

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

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