- From: Aymeric Vitte <vitteaymeric@gmail.com>
- Date: Thu, 04 Apr 2013 22:21:54 +0200
- To: Mark Watson <watsonm@netflix.com>
- CC: "public-webcrypto@w3.org" <public-webcrypto@w3.org>, GALINDO Virginie <Virginie.GALINDO@gemalto.com>
- Message-ID: <515DE0E2.5040005@gmail.com>
OK, then :
let copy be a copy of the list of pending data --> let copy be a copy of
the list of pending data and associated crypto op context
restore the list of pending data with copy --> restore the list of
pending data and associated crypto op context with copy
So in practice this is an internal clone, not an external one exposed to
js, which makes a difference.
Whether the principles of the proposal are good or not, if the group
does not specify this now it might be impossible to recover later, I
don't really like the fact to add resume and final attributes, maybe
it's not really necessary (because for example if you recover the
context, you should recover the previous result), but don't see for now
how to do this better, that's a first approach which probably can be
improved.
Regards,
Le 04/04/2013 19:56, Mark Watson a écrit :
>
>
> On Thu, Apr 4, 2013 at 10:42 AM, Aymeric Vitte <vitteaymeric@gmail.com
> <mailto: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 <mailto: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.
>>>>
>>>>
>>>> |interfaceCryptoOperation : EventTarget {
>>>> voidprocess <http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation-method-process>(ArrayBufferView buffer);
>>>> voidfinish <http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation-method-finish>(boolean? resume);
>>>> voidabort <http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation-method-abort>();
>>>>
>>>> readonly attributeKey <http://www.w3.org/TR/WebCryptoAPI/#dfn-Key>?key <http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation-key>;
>>>> readonly attributeAlgorithm <http://www.w3.org/TR/WebCryptoAPI/#dfn-Algorithm> algorithm <http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation-algorithm>;
>>>> readonly attribute anyresult <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
>>>> specifiedalgorithm
>>>> <http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation-algorithm>does
>>>> not support multi-part cryptographic operations,
>>>> asynchronouslyprocess 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 thelist of pending data
>>>> <http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation-list-of-pending-data>have
>>>> beenprocessed
>>>> <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>tofire 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.
>>>>
>>>> Letdatabe the data to be processed.
>>>>
>>>> 3.
>>>>
>>>> Adddatato thelist 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
>>>> specifiedalgorithm
>>>> <http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation-algorithm>supports
>>>> multi-part cryptographic operations, asynchrouslyprocess
>>>> 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 <mailto: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 <http://www.jcore.fr>
>>>> Webble :www.webble.it <http://www.webble.it>
>>>> Extract Widget Mobile :www.extractwidget.com <http://www.extractwidget.com>
>>>> BlimpMe! :www.blimpme.com <http://www.blimpme.com>
>>
>> --
>> jCore
>> Email :avitte@jcore.fr <mailto: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 <http://www.jcore.fr>
>> Webble :www.webble.it <http://www.webble.it>
>> Extract Widget Mobile :www.extractwidget.com <http://www.extractwidget.com>
>> BlimpMe! :www.blimpme.com <http://www.blimpme.com>
>
> --
> jCore
> Email :avitte@jcore.fr <mailto: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 <http://www.jcore.fr>
> Webble :www.webble.it <http://www.webble.it>
> Extract Widget Mobile :www.extractwidget.com <http://www.extractwidget.com>
> BlimpMe! :www.blimpme.com <http://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
Received on Thursday, 4 April 2013 20:20:02 UTC