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: Sun, 16 Dec 2012 11:40:20 -0800
Message-ID: <CACvaWvbb4TTQu5jEtPwukXqttnW0ObJ2ACc1HE-CO-SK1NrNUw@mail.gmail.com>
To: Aymeric Vitte <vitteaymeric@gmail.com>
Cc: public-webcrypto-comments@w3.org
On Sun, Dec 16, 2012 at 10:36 AM, Aymeric Vitte <vitteaymeric@gmail.com> wrote:
> Trying to summarize here the different emails :
> Le 14/12/2012 19:52, Ryan Sleevi a écrit :
> Then what you want has nothing to do with "streaming", nor
> "progressive", nor "multi-part".
> Yes it has (or please re-explain your concept of streaming)
> What you want has nothing to do with the behaviour/implementation of
> .process()
> See below
> What you want relates to ISSUE-22 (
> http://www.w3.org/2012/webcrypto/track/issues/22 ): Cloning.It's very clear
> you're cloning the digest context via the call to
> EVP_MD_CTX_copy. That is the same as a clone method.
> No, I (or others) am(are) not cloning the CryptoOperation, just the context
> (which is a kind of not so nice hook/hack), nothing to do with a clone
> method, which does not exist in js/TC39
> Le 14/12/2012 19:54, Ryan Sleevi a écrit :
> I already explained to you how intermediate results are made available
> from methods that do support intermediate results - such as
> encryption.
> No, you just explained that progress can fire whenever the UA likes it, or I
> missed it, then please explain how we can get the intermediate results "1:1"
> Digesting does not support intermediate results. You MUST clone the
> digest state, because there is a destructive finalization step.
> Cloning is ISSUE-22.
>> Maybe a solution could be to reuse the crypto operation after finish (and
>> then add something like a destroy method to CryptoOperation)
> This is not possible.
> The spec does not say what happens to the crypto operation after finish
>> With simple ArrayBuffers, what's the problem with calculating separately
>> the digest over A and A|B ? ( | = concatenation). Is it just to optimize so
>> that we don't do the work for A twice ?
> Yes. That is the use case. Until you finalize a digest, you can clone
> the state and re-use it.
> For HMAC, for example, the use case was given that you can compute the
> IPAD/OPAD expansion of the key, and then clone that state, as a way to
> reduce the number of computations you have to do.
> The same would apply for storing the intermediate state of digest(A),
> before it had been finalized (by appending the padding and length).
> That way, the implementation does not have to recompute digest(A`)
> when computing digest(A|B).
> This is a valid use case, no question, but it's a potentially
> problematic one, hence why it has not *yet* been addressed in the
> Editor's Draft, and exists as ISSUE-22 -
> http://www.w3.org/2012/webcrypto/track/issues/22
> Issue 22 is talking about cloning the crypto operation, not the state,
> cloning the state could occur after finish and being reused, this seams
> easier than any cloning operation.
> --
> jCore
> Email :  avitte@jcore.fr
> GitHub : https://www.github.com/Ayms
> Web :    www.jcore.fr
> Webble : www.webble.it
> Extract Widget Mobile : www.extractwidget.com
> BlimpMe! : www.blimpme.com

Just so it's clear,

Everything you so far have expressed a desire for is summed up in ISSUE-22.

While the semantics you desire are not at possible nor likely, the
ability to accomplish cloning of internal state for purposes of
computing hash extensions is reflected in ISSUE-22.

It is not guaranteed that ISSUE-22 will be resolved for this first version.

Received on Sunday, 16 December 2012 19:40:48 UTC

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