- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 21 Dec 2010 11:58:00 -0800
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: Glenn Maynard <glenn@zewt.org>, public-webapps@w3.org
On Mon, Dec 20, 2010 at 5:49 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > On 12/20/10 7:42 PM, Glenn Maynard wrote: >> >> Has a hash functions API been considered, so browsers can expose, for >> example, a native SHA-1 implementation? Doing this in JS is possible, >> but painfully slow, even with current JS implementations. > > Before we go further into this, can we quantify "painfully slow" so we have > some idea of the magnitude of the problem? > > Using the testcase at https://bugzilla.mozilla.org/attachment.cgi?id=487844 > but modifying the input string to be 768 chars, I see a current js > implementation on modern laptop hardware take around 7 seconds to hash it > 50,000 times. I get similar times for an MD5 implementation I found and chopped down. > So I guess the question is how much data we want to be pushing through the > hash function and what throughput we expect, and whether we think JS engines > simply won't get there or will take too long to do so. Notice that all three of the OP's use-cases were based on checksumming files. I don't know how reading in a Blob and then hashing it would compare to just hashing an equivalent string, but I suspect it would have a decent perf hit. This seems like a pretty useful ability in general, enough so that it's probably worthwhile to build it in directly as a Blob.checksum() function or something. I still think it may be useful for the security use-case as well, where you explicitly want a slow hash to begin with. If JS imposes a slowdown on top of that, it could render a good hash too slow to actually use in practice. Plus, you have to depend on the hash implementation you pulled off the web or hacked together yourself, which you probably didn't manually verify before starting to use. ~TJ
Received on Tuesday, 21 December 2010 19:58:55 UTC