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

Re: Streaming - [Re: CryptoOperation and its life cycle]

From: Ryan Sleevi <sleevi@google.com>
Date: Thu, 13 Dec 2012 14:34:10 -0800
Message-ID: <CACvaWvYYpPLiVvktYzdkdHghiHo13znjtk7UYy+d_k3n0-eezg@mail.gmail.com>
To: Aymeric Vitte <vitteaymeric@gmail.com>
Cc: public-webcrypto-comments@w3.org
On Thu, Dec 13, 2012 at 2:27 PM, Aymeric Vitte <vitteaymeric@gmail.com> wrote:
> What I would like to do seems not easy (of course one shot operations are
> easier), but it's not a marginal case, it has been requested a lot of time
> on some projects (node.js) and a living example is
> https://github.com/Ayms/node-Tor (both for hash and encryption)
> The proposed solution is :
> var h1 = window.crypto.digest("SHA1");
> var h2 = window.crypto.digest("SHA1");
> h1.process(stream1);
> h2.process(stream1);
> h2.process(stream2);
> h1.finish();
> h2.finish();
> This is not a streaming solution, and I would not promote clones as well at
> all.
> But the promises style (which I believe just complicate a lot the proposal
> although almost everybody seem to agree that's the right way to spec things)
> does not make clear what happens to the list of pending datas while
> different process methods are invoked successively, first I wrote :
> H.process(stream1);
> H.process(stream2);
> H.onprogress=function() { console.log(this.result)};
> Then I thought that it was completely wrong (is stream2 processed by
> H.process(stream1) ?)
> Unlike other APIs, you don't have any update method, but why not just simply
> when process method ends :
> - return digest of process method
> - put remaining blocks (ie the ones that would not have been processed by un
> update method) in pending datas as the oldest ones
> But still I don't know what would fire onprogress exactly...
> Again, I might be misreading, the intention here is to move forward, not to
> complicate things

I'm not ignoring your example, but quite simply, I don't believe what
you wrote matters at all in the case of digest.

For all of the supported digest functions, there is an explicit
finalization step, as dictated by the algorithm definition, which
involves padding and including the length. That is, there is NEVER any
output that returns a "partial" hash, because there is no such thing.

If we're going to talk about this, I want to make sure we're actually
talking about a valid use case. Because digesting is not one. If
you're only concerned about digesting, then I fear you may be
misinformed, but it does make the rest of the conversation much

Received on Thursday, 13 December 2012 22:34:38 UTC

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