On Mon, Dec 20, 2010 at 5:49 PM, Boris Zbarsky <bzbar...@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

Reply via email to