W3C home > Mailing lists > Public > public-webcrypto-comments@w3.org > November 2012

Re: File hashing and progressive computation

From: Artem Skoretskiy <tonn81@gmail.com>
Date: Sun, 4 Nov 2012 16:54:18 +0100
Message-ID: <CAGLVQBb53BLD8hD420XA+GoxhW9CkK-r06-ouGmNNBF0Hnd2wA@mail.gmail.com>
To: Ryan Sleevi <sleevi@google.com>
Cc: "public-webcrypto-comments@w3.org" <public-webcrypto-comments@w3.org>
See some comments inline.

2012/11/4 Ryan Sleevi <sleevi@google.com>
>
>
> On Nov 4, 2012 11:22 AM, "Artem Skoretskiy" <tonn81@gmail.com> wrote:
> >
> > 1. *MD5 digest*.
>
> I agree with the idea in general, but support for weak algorithms -
> particularly those that are easily misused by developers - has been a point
> of contention. Every algorithm specified is a tacit encouragement of use.
>
> Are you sure that, at this point, the differences are not minor to
> non-existant between sha-1? Alternatively, are you sure a simple CRC is not
> desired here?

I completely agree with your points -- MD5 algorithm is weak and
should not be used for any real cryptography like signing and
crypt/decrypt. We have a solution - as far as I get from the
specification - every algorithm can be limited to specific actions.
Then it can be simply limited to getting hash only.

It is more question of interoperability -- I'd prefer to use CRC32 or
SHA1 for hashing files -- but often you have to deal with legacy or
external systems that do not provide any alternatives to MD5. Then as
a developer instead of shiny standard and performance Crypto API I
would have to use some 3rd party JS libraries to interact with those
systems.

In witness for MD5 algorithm I would say it is fast, [quite] easy to
implement and produce good results when used for generating data
fingerprint (hash).

>
> > 2. *Blob as input parameter* for CryptoOperation.processData
> >
> There is already an open issue on this (the reference is not handy). It
> was originally included, but removed for now due to various canonicalization
> ambiguities regarding Blob that do not exist with ArrayBuffer.
>
> As an implementer, yes, the desire is to support Blob/File as well.

Looking forward to see support of Blob/File in the specification. I'm
sure browser developers will catch pretty fast.

>
> >
> >
> > 3. *Progressive hash calculation*.
> >
> This is already supported. That is exactly what processData is for - the
> equivalent of update() - for hashing, encrypt, decrypt, and verify.

Great. Then documentation should be updated to make it more clear.
Something that processData can be used multiple times to process a big
data. Maybe an example of getting hash of big data will make it more
obvious.
Received on Sunday, 4 November 2012 15:54:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 4 November 2012 15:54:45 GMT