- From: Aymeric Vitte <vitteaymeric@gmail.com>
- Date: Thu, 04 Apr 2013 18:23:36 +0200
- To: Mark Watson <watsonm@netflix.com>
- CC: "public-webcrypto@w3.org" <public-webcrypto@w3.org>, GALINDO Virginie <Virginie.GALINDO@gemalto.com>
- Message-ID: <515DA908.20609@gmail.com>
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?)
> 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
>> 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
Received on Thursday, 4 April 2013 16:21:36 UTC