- From: Takeshi Yoshino <tyoshino@google.com>
- Date: Thu, 7 Nov 2013 18:42:21 +0900
- To: Aymeric Vitte <vitteaymeric@gmail.com>
- Cc: "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>
- Message-ID: <CAH9hSJZr0zmjH3OjYtcMc+a3pEb74CKvxieGDR_HucFuvP46rA@mail.gmail.com>
On Thu, Nov 7, 2013 at 6:27 PM, Aymeric Vitte <vitteaymeric@gmail.com>wrote: > > Le 07/11/2013 10:21, Takeshi Yoshino a écrit : > > On Thu, Nov 7, 2013 at 6:05 PM, Aymeric Vitte <vitteaymeric@gmail.com>wrote: > >> stop/resume: >> >> Indeed as I mentioned this is related to WebCrypto Issue22 but I don't >> think this is a unique case. Issue22 was closed because of lack of >> proposals to solve it, apparently I was the only one to care about it (but >> I saw recently some other messages that seem to be related), and finally >> this would involve a public clone method with associated security concerns. >> >> But with Streams it could be different, the application will internally >> clone the state of the operation probably eliminating the security issues, >> as simple as that. >> >> To describe simply the use case, let's take a progressive hash computing >> 4 bytes by 4 bytes: >> >> incoming stream: ABCDE bytes >> hash operation: process ABCD, keep E for the next computation >> incoming stream: FGHI bytes + STOP-EOF >> hash operation: process EFGH, process STOP-EOF: clone the state of the >> hash, close the operation: digest hash with I >> > > So, here, partial hash for ABCDEFGH is output > > > No, you get the digest for ABCDEFGHI and you get a cloned operation which > will restart from ABCDEFGH > > > OK. > > >> >> resume: >> incoming stream: JKLF >> hash operation (clone): process IJKL, keep F for next computation >> etc... >> >> > and if we close the stream here we'll get a hash for ABCDEFGHIJKLFPPP (P > is padding). Right? > > > If you close the stream here you get the digest for ABCDEFGHIJKLF > > resume happens implicitly when new data comes in without explicit method call say resume()? > > > >> So you do not restart the operation as if it was the first time it was >> receiving data, you just continue it from the state it was when stop was >> received. >> >> That's not so unusual to do this, it has been requested many times in >> node. >> > > -- > Peersm : http://www.peersm.com > node-Tor : https://www.github.com/Ayms/node-Tor > GitHub : https://www.github.com/Ayms > >
Received on Thursday, 7 November 2013 09:43:09 UTC