Re: File hashing and progressive computation

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