- From: Aymeric Vitte <vitteaymeric@gmail.com>
- Date: Sat, 16 Feb 2013 00:43:40 +0100
- To: Ryan Sleevi <sleevi@google.com>
- CC: Richard Barnes <rbarnes@bbn.com>, public-webcrypto-comments@w3.org
Let's try... basically I am saying that ISSUE 22 is not only about hash but encryption too and the conclusion should be that a clone method should be added. cryptoJS behaviour is a good example, as stated in issue 73, update does not process all the blocks even if it could (ie no padding), you have to call final to get all the blocks processed. But other implementations like openssl do not behave the same, update does return all the blocks processed. Then for example, if you take a progressive encryption like tor protocol with aes-ctr : openssl : stream1 (509 bytes) --> update --> stream1 encrypted (result=509 bytes encrypted - 0 byte remaining) cryptoJS : stream 1 (509 bytes) --> update --> stream 1 encrypted (result=496 bytes encrypted - 13 bytes remaining) openssl : stream2 (509 bytes) --> update --> continue encryption with 0 remaining byte - result = 509 bytes (corresponds to the last 509 bytes of stream1+stream2 encrypted - 0 byte remaining) cryptoJS : stream 2 (509 bytes) --> update --> continue encryption with 13 remaining bytes - result = 512 bytes (corresponds to the last 512 bytes of 496 bytes of stream1+13 remaining bytes+ part of stream2 (499 bytes) encrypted - 10 bytes remaining) So, with the cryptoJS behaviour, only 496 bytes of the initial 509 bytes would be encrypted and sent, then stream2 would contain the 13 last encrypted bytes of stream1 + 499 encrypted bytes of stream2. Of course, since each stream might not contain only pure streamed information (like file, img, etc) but can contain instructions (like encrypted(connect to mydomain.com)), you do not expect to receive these instructions in different parts that you can not reconciliate, and you can not wait for stream2 if you detect that stream1 encryption is not complete, because stream2 might depend on stream1 action, therefore never come. If you call final at each step, then you close the encryptor and just get stream1 encrypted, then stream2 encrypted (not last 509 bytes of stream1+stream2 encrypted), etc The solution here is issue 74, ie clone. I did not invent it, that's the way it's working with tor protocol, I have some hard time understanding why the stream length chosen is not a multiple of something that could be computed by an update without any potential remaining bytes, or what is the official policy for update (should it return whatever blocks it can process or not), but that's the way it is, and again it's not something from myself. Regards, Le 15/02/2013 19:49, Ryan Sleevi a écrit : > On Fri, Feb 15, 2013 at 5:55 AM, Aymeric Vitte <vitteaymeric@gmail.com> wrote: >> This reminds me that I should have sent an erratum of my erratum sent for >> the encryption case related to Issue 22. >> >> See http://code.google.com/p/crypto-js/issues/detail?id=73#c3 , issue >> addressed to cryptoJS and finally accepted. >> >> And see following issue (clone) : >> http://code.google.com/p/crypto-js/issues/detail?id=74 >> >> This is a real life use case, current implementation of cryptoJS, contrarly >> to others, does not process all blocks when it can on "update", then you >> have to call "final" which closes the encryptor (same as finish below). >> >> I don't know who is right or wrong and if there is an official rule for >> this, but it does not seem unlogical that cryptoJS "update" returns a >> partial result (same as Ryan explained for process/progress results which >> are let to the appreciation of the UA), even if other implementations do >> return "final". >> >> But then I can not achieve what I want to do, and I must use a clone method >> for this. >> >> So, Issue 22 can be about encryption too, probably a clone method is needed. > I'm sorry Aymeric, but having both read your reply and the bug, I'm > having trouble understanding what it is you're actually asking or > suggesting is a bug, nor what you're trying to do (or if it even makes > sense from a cryptographic security perspective). > > Could you perhaps try restating? -- 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 Friday, 15 February 2013 23:41:12 UTC