Re: [W3C Web Crypto WG] PROPOSAL to close ISSUE-22 (Should CryptoOperations be clonable)

On Thu, Apr 4, 2013 at 10:42 AM, Aymeric Vitte <vitteaymeric@gmail.com>wrote:

>
> Le 04/04/2013 18:23, Aymeric Vitte a écrit :
>
>
> Le 04/04/2013 16:12, Mark Watson a écrit :
>
> Unless I am missing something, if multi-part operations are permitted
>
> Not clear about this, what is a multi-part operation exactly (example?)
>
> , then in the complete step the variable copy contains only the data since
> the last process. I don't see where you reset the state of the operation to
> the same point.
>
>  I am assuming that the operation can restart from the last known pending
> data + result (wrong?)
>
>
> Precision : since the API processing model does not detail what happens in
> the underlying crypto algorithm and the visible elements are the pending
> data and result, I am assuming that by some internal mechanisms the crypto
> algorithm can restart from the state it was with these elements (ie the
> context is copied when you copy pending data and restored when you restore
> it)
>

Yep, my point was that you need to state this. i.e. the procedures need to
state that the internal state of the operation is reverted to what it was
before finish() was called. It's not enough to say that only the externally
visible attributes are restored. The list of pending data is not the only
internal state.

...Mark


>
>
>  Anyway, this seems like a premature optimization. It complicates the API
> and procedures for a minor use-case which could be achieved (marginally
> less optimally) by keeping multiple CryptoOperation objects, one for each
> prefix of the input data for which a digest is required.
>
> I am not sure it's so minor or will be minor in the future, without it I
> can not do [1] and probably SSL/TLS implementation with the API, the
> solution of having multiple CryptoOperations is impossible in terms of
> performances
>
> [1] https://www.github.com/Ayms/node-Tor
>
>
>  ...Mark
>
> Sent from my iPhone
>
> On Apr 4, 2013, at 5:18 AM, Aymeric Vitte <vitteaymeric@gmail.com> wrote:
>
>   If ISSUE-22 is closed, then it becomes impossible to do correctly
> progressive hash/encryption with the WebCrypto API.
>
> This might be destroyed right away but please see below a proposal, it is
> not really a clone but a continuation of the operation resuming from the
> previous state (which as a non crypto expert maybe I am simplifying too
> much), see the example at the end, at least that's an attempt...
>
> This is based on the assumption than independently of which progress could
> be fired following some process invocations at the same time you call
> finish, you are only interested by the final result.
>
>
> interface CryptoOperation : EventTarget {
>   void process <http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation-method-process>(ArrayBufferView buffer);
>   void finish <http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation-method-finish>(boolean? resume);
>   void abort <http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation-method-abort>();
>
>   readonly attribute Key <http://www.w3.org/TR/WebCryptoAPI/#dfn-Key>? key <http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation-key>;
>   readonly attribute Algorithm <http://www.w3.org/TR/WebCryptoAPI/#dfn-Algorithm> algorithm <http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation-algorithm>;
>   readonly attribute any result <http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation-result>;  readonly attribute any? resume <http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation-result>;  readonly attribute any? final;
>
>
> 12.4.2. The finish(boolean? resume) method
>
> When finish(boolean? resume)<http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation-method-finish>
>  method is called, the user agent must run the steps below.
>
>    1.
>
>    If the internal state is in the "error" state, throw an
>    InvalidStateError exception and abort these steps.
>     2.
>
>    Set the internal state to "complete". If resume is true let copy be a
>    copy of the list of pending data and set the resume attribute to result
>     3.
>
>    If the underlying cryptographic implementation for the specified
>    algorithm<http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation-algorithm>
>     does not support multi-part cryptographic operations, asynchronously process
>    data<http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation-process-data>,
>    allowing the task that invoked this algorithm to continue.
>     4.
>
>    Once all items in the list of pending data<http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation-list-of-pending-data>
>     have been processed<http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation-process-data>
>    , if resume is true, restore the list of pending data with copy and
>    set final to result, queue a task<http://www.w3.org/TR/WebCryptoAPI/#queue-a-task>
>     to fire a simple event<http://www.w3.org/TR/WebCryptoAPI/#fire-a-simple-event>
>     called oncomplete<http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation-oncomplete>
>     at the CryptoOperation<http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation>
>    .
>
>
> 12.4.1. process(ArrayBufferView data)
>
> When the process(ArrayBufferView data) method is called, the user agent
> must run the following steps:
>
>    1.
>
>    If the internal state is in the "error" state, throw an
>    InvalidStateError exception and abort these steps.
>     2.
>
>    Let data be the data to be processed.
>     3.
>
>    Add data to the list of pending data<http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation-list-of-pending-data>
>    .
>     4. If the resume attribute is not undefined, update result with resume
>     5.
>
>    If the underlying cryptographic implementation for the specified
>    algorithm<http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation-algorithm>
>     supports multi-part cryptographic operations, asynchrously process
>    data<http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation-process-data>,
>    allowing the task that invoked this algorithm to continue.
>
> Example :
>
> The algorithm processes 3 bytes :
>
> process(ABCD) {result=abc, pending=D}
> finish(true) {result=abcd,final=abcd,resume=abc,pending=D}
> process(EFGH)
>     step 4 {result=abc,final=abcd,resume=abc,pending=D}
>     step 5 {result=abcdefg,final=abcd,resume=abc,pending=H}
> finish(true) {result=abcdefgh,final=abcdefgh,resume=abcdefg,pending=H}
>
> The reason to use final attribute is that process does modify result and
> then progress could fire before complete and then the result in complete
> would not be the good one.
>
>
> Le 04/04/2013 11:46, GALINDO Virginie a écrit :
>
>  Dear all,
>
> I suggest that we close the ISSUE-22
> http://www.w3.org/2012/webcrypto/track/issues/22 , with the rationale
> that the WG did not make any progress /contribution on cloning. As such I
> interpret it as no interest or need to have that feature covered by our Web
> Crypto API.
>
> This proposal will be submitted to the vote during our next call on the 15
> th of April.
>
> Regards,
>
> Virginie
>
>
>
>
> --
> jCore
> Email :  avitte@jcore.fr
> iAnonym : http://www.ianonym.com
> node-Tor : https://www.github.com/Ayms/node-Tor
> GitHub : https://www.github.com/Ayms
> Web :    www.jcore.fr
> Webble : www.webble.it
> Extract Widget Mobile : www.extractwidget.com
> BlimpMe! : www.blimpme.com
>
>
> --
> jCore
> Email :  avitte@jcore.fr
> iAnonym : http://www.ianonym.com
> node-Tor : https://www.github.com/Ayms/node-Tor
> GitHub : https://www.github.com/Ayms
> Web :    www.jcore.fr
> Webble : www.webble.it
> Extract Widget Mobile : www.extractwidget.com
> BlimpMe! : www.blimpme.com
>
>
> --
> jCore
> Email :  avitte@jcore.fr
> iAnonym : http://www.ianonym.com
> node-Tor : https://www.github.com/Ayms/node-Tor
> GitHub : https://www.github.com/Ayms
> Web :    www.jcore.fr
> Webble : www.webble.it
> Extract Widget Mobile : www.extractwidget.com
> BlimpMe! : www.blimpme.com
>
>