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

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