Re: ISSUE 22 - Re: Incomplete blocks

I'm sorry, I've read this several times, and the related bug, and am
still having trouble what you're asking about or why you feel .clone()
is appropriate here.

.clone() is something especially dangerous for encryption, given that
for most systems, it will result in a catastrophic failure (eg: due to
IV reuse).

// Using pseudo-code here, not the actual API
var a = window.crypto.encrypt(..., {... { iv: 1 } })
a.process('abcd');  // Encrypts under IV 1, Increments IV to 2
var b = a.clone();  // b.iv == 2
a.process('efgh');  // Encrypts under IV 2, increments IV to 3
b.process('ijlk');  // Encrypts under **IV 2**, increments IV to **3**

In this case, a and b have no collided under IVs for the same key.
Very, very bad things happen.

Under the model, process always consumes all of the data given to it.
As best I can tell, this is your "OpenSSL" example. But it's not clear
at all based on your description, so it would be helpful if you could
try to simplify your example with the actual primitives needed.

On Fri, Feb 15, 2013 at 3:43 PM, Aymeric Vitte <vitteaymeric@gmail.com> wrote:
> 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 Saturday, 16 February 2013 00:03:56 UTC