- From: Ryan Sleevi <sleevi@google.com>
- Date: Fri, 15 Feb 2013 15:57:50 -0800
- To: Aymeric Vitte <vitteaymeric@gmail.com>
- Cc: Richard Barnes <rbarnes@bbn.com>, public-webcrypto-comments@w3.org
Aymeric, I'm sorry. I still do not understand what you're asking for. On Fri, Feb 15, 2013 at 3:54 PM, Aymeric Vitte <vitteaymeric@gmail.com> wrote: > For openssl to be clear : > > "0 byte remaning"="indeed all blocks were processed but to continue the > progressive encryption, restart from the 13 last bytes for next step" > "continue encryption with 0 remaining byte" = "restart encryption from the > 13 last bytes state and add 509 bytes, encrypt and call update (ie final)" > > > Le 16/02/2013 00:43, Aymeric Vitte a écrit : >> >> 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:58:19 UTC