- From: Aymeric Vitte <vitteaymeric@gmail.com>
- Date: Thu, 04 Apr 2013 19:42:17 +0200
- To: Mark Watson <watsonm@netflix.com>
- CC: "public-webcrypto@w3.org" <public-webcrypto@w3.org>, GALINDO Virginie <Virginie.GALINDO@gemalto.com>
- Message-ID: <515DBB79.9040600@gmail.com>
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)
>> 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
--
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 17:40:16 UTC