Re: bis : ISSUE 22 - Re: Incomplete blocks

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:51:58 UTC