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

Re: Hash functions

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 20 Dec 2010 16:57:35 -0800
Message-ID: <AANLkTinZza6_rW4UbzANJKKhn19+FFNi28Pku0B6My_h@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: public-webapps@w3.org
On Mon, Dec 20, 2010 at 4:42 PM, Glenn Maynard <glenn@zewt.org> 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.
>
> Some fairly obvious use cases:
>
>  - Avoid uploading a file to the server if it already has a copy.  For
> example, if you attach a large file to an email, and you already have
> a copy of that file in your mailbox attached to another mail, don't
> upload the whole file; just send a reference the existing one.
>  - Resumable file uploads.  An implementation of a chunked, resumable
> uploader will want to validate that the file the user is sending is
> actually what's been received by the server so far, and roll back the
> transfer partially or completely if they're out of sync.
>  - Local file validation and updating.  A web-based game may want to
> save large blocks of resources locally, rather than depending on HTTP
> caching to do it, which is inappropriate for a game with several
> hundred megabytes or more of resources.  Native hashing would help
> automatic updating of data.
>
> If there's a more appropriate place for this, let me know.

I think this would be pretty useful too.  All the good hash functions
are designed to be run in hardware, which means they're slower than
necessary in Javascript, even ignoring js's difficulty in dealing with
raw binary data currently.

At least two hashes should be exposed - a fast one like SHA-1 for
things like checksumming, and a slow one like bcrypt for actual
security/signing uses.

A problem, of course, is that once a browser ships a particular algo,
it can't ever stop shipping it, because even if the author is smart
enough to watch for a changed algo (which most won't), they'll still
need to invalidate all of the currently hashed data or switch back to
a slow software one.  For the same reason, browsers can't ship a
default algorithm (that is, one that you get when you don't explicitly
specify an algorithm), because pretty much all code using the default
will immediately become legacy code that will break if the algo is
switched.

So, the choice of algos used has to be made very carefully.

~TJ
Received on Tuesday, 21 December 2010 00:58:28 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:42 GMT