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

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.

Cheers,
Ryan

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