W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

Re: Hash functions

From: Charles Pritchard <chuck@visc.us>
Date: Wed, 22 Dec 2010 13:39:59 -0800
Message-ID: <4D12702F.3000001@visc.us>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: Boris Zbarsky <bzbarsky@mit.edu>, Glenn Maynard <glenn@zewt.org>, public-webapps@w3.org
On 12/21/2010 11:58 AM, Tab Atkins Jr. wrote:
> 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.

It'd be nice to see an SHA1 JS test case setup for performance testing 
using recent APIs like ArrayBuffer.

These kinds of self-contained functions are low hanging fruit for 
compiler optimization.
"use strict", Typed Arrays and Object.seal give JS compilers a 
reasonable chance
to hit the performance of C compilers.

I've not been able to find a 'public domain' JS SHA1 implementation on 
the web.

If you need a quick hash function, there are faster ones than SHA1.

> 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.
I'd only expect vendors to implement sha1 and md5.

NaCl-LLVM makes sense if you're looking at just porting existing C over 
to the web.
Or the Mozilla ChromeWorker proposal.

Current JS code, BSD licensed SHA1 and MD5 scripts have been through 
extensive open source review.
Sure, a lot of open source code floats around without due review.
They're no different in credibility than BSD licensed code in C.

Received on Wednesday, 22 December 2010 21:40:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:14 UTC