Re:jsSHA - A JavaScript Implementation Of The Entire Family ...
by Cyranix on Wednesday December 05, 2012 @12:22AM
(#4875018)
Can you clarify "broken"? In this context there is a world of difference between "inaccurately implemented" and "slow".
Re:jsSHA - A JavaScript Implementation Of The Entire Family ...
by hdevalence on Wednesday December 05, 2012 @01:13AM
(#4875150)
There's a nice article here:
http://www.matasano.com/articles/javascript-cryptography/
that explains some of the issues with JavaScript-based cryptosystems.
Re:jsSHA - A JavaScript Implementation Of The Entire Family ...
by saurik on Wednesday December 05, 2012 @01:26AM
(#4875183)
Note: these arguments only apply to JavaScript in a browser (and at that point, apply to virtually any client-side system attempting to somehow protect information from being snooped on by the server that dynamically provides the code to execute on the client <- an idea that should have been preposterous from the start ;P).
Re:jsSHA - A JavaScript Implementation Of The Entire Family ...
by Hupo on Wednesday December 05, 2012 @04:27AM
(#4875571)
While it obviously makes no sense to use client-side crypto for verification, there can still be use for things like MD5 and SHA-1 on the client side. I have a script that does SHA-1 hashing for images fetched via XHR, for example (which is used for reverse image searching purposes).
Seeing this, I guess I should do some benchmarking and see whether it gives better speeds than my current implementation (and also look for any other options and test those too).
AFAIK, Stanford is generally accepted to have the most reliable JS crypto library, though all of them are broken as all hell and not usable in anything but toy applications.
https://crypto.stanford.edu/sjcl/