jsSHA - A JavaScript Implementation Of The Entire Family Of SHA Hashes | Hacker News Reader

jsSHA - A JavaScript Implementation Of The Entire Family Of SHA Hashes

caligatio.github.com

27 pointsHirvesh28 comments

Who is this person and why are they qualified to write this library?

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/

Can you clarify "broken"? In this context there is a world of difference between "inaccurately implemented" and "slow".

There's a nice article here:

http://www.matasano.com/articles/javascript-cryptography/

that explains some of the issues with JavaScript-based cryptosystems.

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

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

The google closure library has sha1 and hmac support as well - well worth checking out

http://closure-library.googlecode.com/svn/docs/namespace_goo...

Isn't it well past time browsers got a standard crypto library that couldn't be overridden? Are there any vulnerabilities in that scheme?

You mean like SSL/TLS?

No, a library with crypto primitives that Javascript can access.

The W3C has a crypto API draft at: http://www.w3.org/TR/WebCryptoAPI/

Fantastic, that's very promising.

I'm sorry, but the "entire family of SHA hashes" is incorrect as SHA3 isn't present.

via Functionn - Open Source Resources For Web Developers & Designers: http://functionn.blogspot.com/2012/07/jssha-javascript-imple...

P.S. Functionn contains a whole lot more of awesome resources like jsSHA. There only a fraction of them I can post here at a time. Take a look if you're interested, and subscribe:

http://functionn.blogspot.com

Looking at your comment history, 99.9% of it is links to your own blog. While HN is generally not against self-promotion, you should probably tone it down; I'd be very surprised if it didn't end up getting you banned, as it looks a whole lot like spamming (and really, it is). That said, keep up the good work with your blog, just chill a bit on the constant links.

thank you for the kind words for the blog!

Will take your advice and try not to post too many link. Will try to contribute more to the HN communityin other ways :-)

You are double-posting yourself: http://news.ycombinator.com/item?id=4871546

I'm sorry about that, had posted about jsSHA earlier, but the site was having problems (persistent Gitthub Unicorn Page), so I had to pull it down :)

What would you use an HMAC generated in JavaScript for? I'm trying to think of uses that wouldn't be completely insecure, but I'm coming up empty. You need to have the key client-side, so what's the point?

I imagine this is not sent to the client, and is used for serverside JavaScript applications.

In server-side JavaScript, you'd typically have easy access to non-JS crypto libraries. In node, you have the crypto package, which is a thin wrapper around OpenSSL. In Rhino, you can use Java libraries like Bouncy Castle. And so on.

What about a browser extension, where you enter some api key, before you can use it.

the only situation I could possibly think of is that the key is a user input and the digest is only sent to the server. Then the server could verify knowing that customers key.

Also (shameless plug), if you want to use murmurHash3 in JavaScript: https://github.com/karanlyons/murmurHash3.js

looks interesting, how does it compare to SHA hashes?

MurmurHash isn't secure and isn't intended to be. The algorithm is intended for fast non-cryptographic hashing for non-secure hashing needs. Whether or not people will use them only in cases where they really don't need any security in their hash (an attacker could cause a denial of service or a slowdown of service by degrading the performance of core data-structures if you use a non-secure hash function against untrusted inputs in the wrong contexts) is somewhat up in the air.

That said, it's being used by real applications in production, so the niche is definitely there, but for anything that needs any level of security you should continue using a secure hash algorithm, of which the unimaginably named SHA family provides a good set of standard algorithms. Using a secure hash every place you need a hashing algorithm unless you know you'll need the extra perf and know you can get away with it is probably a reasonable practice.

You might also be interested in SipHash, a cryptographic MAC that's fast enough to use in hash tables. If you want to avoid those denial of service attacks, it's a good candidate.

https://www.131002.net/siphash/

I started using it last week to calculate a fingerprint of a set of files (http://cburgmer.github.com/csscritic/)

There's also a proposal to have crypto added as a native API.

http://www.w3.org/TR/WebCryptoAPI/

Reply on news.ycombinator.com