- From: Artem Skoretskiy <tonn81@gmail.com>
- Date: Sun, 4 Nov 2012 16:54:18 +0100
- 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 UTC