Le 07/11/2013 10:21, Takeshi Yoshino a écrit :
On Thu, Nov 7, 2013 at 6:05 PM, Aymeric Vitte <[email protected]
<mailto:[email protected]>> 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
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
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
