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

Re: File hashing and progressive computation

From: Ryan Sleevi <sleevi@google.com>
Date: Mon, 5 Nov 2012 06:53:35 -0800
Message-ID: <CACvaWvajKmmYN_c-cAK3z_HEYmfTpLSnsv1vEDgbfYeGAF8LQg@mail.gmail.com>
To: Artem Skoretskiy <tonn81@gmail.com>
Cc: "public-webcrypto-comments@w3.org" <public-webcrypto-comments@w3.org>
On Sun, Nov 4, 2012 at 7:54 AM, Artem Skoretskiy <tonn81@gmail.com> wrote:
> 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.

Individually speaking, I don't feel like it's the end of the world if
some algs have to fall back to polyfill, if there is an active reason
not to include them. I would argue that MD5 has enough reasons against
it to actively not include it, but that's for the WG. We currently
haven't really established any baseline criteria for
including/excluding algorithms though, so it's a bit of a toss-up.

> 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.

Thanks for the feedback. Raised as
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19862 for addressing in
the next rev in the spec.
Received on Monday, 5 November 2012 14:54:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:12:49 UTC