- 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