Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Zip & encrypt resource
Zip & encrypt resource [message #635894] Thu, 28 October 2010 14:11 Go to next message
Eclipse UserFriend
Originally posted by: koen.yskout.cs.kuleuven.be

Hi,

As mentioned before in this newsgroup, and in bug 261620
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=261620) which was marked
as 'verified fixed' a while ago, zipping should happen before
encryption; otherwise the zipping has no effect. Nevertheless, when I
use OPTION_ZIP and OPTION_CIPHER simultaneously, the file is encrypted
first, and then zipped (the resulting file starts with 'PK', and can be
unzipped)...

Can this still be fixed? This would break existing implementations that
already use both options, though. Alternatively, is there a clean
workaround? As the save(OutputStream, Map) method from ResourceImpl is
final, I cannot override this behavior in my custom resource class :(

Kind regards,

Koen
Re: Zip & encrypt resource [message #636005 is a reply to message #635894] Thu, 28 October 2010 21:53 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30541
Registered: July 2009
Senior Member
Koen,

It wouldn't be a valid zip file if it was encrypted the other way...


Koen Yskout wrote:
> Hi,
>
> As mentioned before in this newsgroup, and in bug 261620
> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=261620) which was marked
> as 'verified fixed' a while ago, zipping should happen before
> encryption; otherwise the zipping has no effect. Nevertheless, when I
> use OPTION_ZIP and OPTION_CIPHER simultaneously, the file is encrypted
> first, and then zipped (the resulting file starts with 'PK', and can be
> unzipped)...
>
> Can this still be fixed? This would break existing implementations that
> already use both options, though. Alternatively, is there a clean
> workaround? As the save(OutputStream, Map) method from ResourceImpl is
> final, I cannot override this behavior in my custom resource class :(
>
> Kind regards,
>
> Koen
>
Re: Zip & encrypt resource [message #636095 is a reply to message #636005] Fri, 29 October 2010 09:40 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: koen.yskout.cs.kuleuven.be

Ed,

I'm not sure I understand your reply; I assume the goal of OPTION_ZIP is
not to obtain a valid zip file, but to reduce the size of the file (at
least, that's how I want it to work :p).

A good symmetric crypto algorithm leaves no redundancy in its outcome
and (approximately) preserves the size of the input. So if the contents
is encrypted before it is zipped, the zipping has no effect on the size
and is pointless. This is how the current implementation seems to work.

Alternatively, first zipping would give a smaller input to encrypt, and
*does* result in a smaller file. Of course, the resulting file is then
an encrypted binary blob and not a valid zipfile; the zip only appears
after decryption. I don't see a problem with this, though.

To illustrate, I did some experiments (using the AES cipher):

* no save options ==> 18 Kb [ plain ]
* only OPTION_ZIP ==> 1.4 Kb [ zip(plain) ]
* only OPTION_CIPHER ==> 18 Kb [ encrypt(plain) ]
* OPTION_CIPHER and OPTION_ZIP ==> 18 Kb [ zip(encrypt(plain)) ]
^- this is what the current implementation gives
* ??? ==> 1.5 Kb [ encrypt(zip(plain)) ]
^- this is what I want (currently obtained using command line)

Maybe a new option (e.g., OPTION_COMPRESSED_BEFORE_CIPHERED [Boolean])
is a backwards-compatible extension that can enable this behavior?

Koen



On 28/10/10 23:53, Ed Merks wrote:
> Koen,
>
> It wouldn't be a valid zip file if it was encrypted the other way...
>
>
> Koen Yskout wrote:
>> Hi,
>>
>> As mentioned before in this newsgroup, and in bug 261620
>> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=261620) which was marked
>> as 'verified fixed' a while ago, zipping should happen before
>> encryption; otherwise the zipping has no effect. Nevertheless, when I
>> use OPTION_ZIP and OPTION_CIPHER simultaneously, the file is encrypted
>> first, and then zipped (the resulting file starts with 'PK', and can be
>> unzipped)...
>>
>> Can this still be fixed? This would break existing implementations that
>> already use both options, though. Alternatively, is there a clean
>> workaround? As the save(OutputStream, Map) method from ResourceImpl is
>> final, I cannot override this behavior in my custom resource class :(
>>
>> Kind regards,
>>
>> Koen
>>
Re: Zip & encrypt resource [message #636127 is a reply to message #636095] Fri, 29 October 2010 12:19 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 30541
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------090508070707060108040607
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Koen,

Comments below.

Koen Yskout wrote:
> Ed,
>
> I'm not sure I understand your reply; I assume the goal of OPTION_ZIP is
> not to obtain a valid zip file, but to reduce the size of the file (at
> least, that's how I want it to work :p).
>
It is intended to produce something that can be unzipped, but I'm not
sure that was such an important goal,
> A good symmetric crypto algorithm leaves no redundancy in its outcome
> and (approximately) preserves the size of the input. So if the contents
> is encrypted before it is zipped, the zipping has no effect on the size
> and is pointless. This is how the current implementation seems to work.
>
> Alternatively, first zipping would give a smaller input to encrypt, and
> *does* result in a smaller file. Of course, the resulting file is then
> an encrypted binary blob and not a valid zipfile; the zip only appears
> after decryption. I don't see a problem with this, though.
>
No, I guess that would be okay.
> To illustrate, I did some experiments (using the AES cipher):
>
> * no save options ==> 18 Kb [ plain ]
> * only OPTION_ZIP ==> 1.4 Kb [ zip(plain) ]
> * only OPTION_CIPHER ==> 18 Kb [ encrypt(plain) ]
> * OPTION_CIPHER and OPTION_ZIP ==> 18 Kb [ zip(encrypt(plain)) ]
> ^- this is what the current implementation gives
> * ??? ==> 1.5 Kb [ encrypt(zip(plain)) ]
> ^- this is what I want (currently obtained using command line)
>
> Maybe a new option (e.g., OPTION_COMPRESSED_BEFORE_CIPHERED [Boolean])
> is a backwards-compatible extension that can enable this behavior?
>
Yes, we'd not want to break people. Though you have to wonder if they
were doing something pointless...
> Koen
>
>
>
> On 28/10/10 23:53, Ed Merks wrote:
>
>> Koen,
>>
>> It wouldn't be a valid zip file if it was encrypted the other way...
>>
>>
>> Koen Yskout wrote:
>>
>>> Hi,
>>>
>>> As mentioned before in this newsgroup, and in bug 261620
>>> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=261620) which was marked
>>> as 'verified fixed' a while ago, zipping should happen before
>>> encryption; otherwise the zipping has no effect. Nevertheless, when I
>>> use OPTION_ZIP and OPTION_CIPHER simultaneously, the file is encrypted
>>> first, and then zipped (the resulting file starts with 'PK', and can be
>>> unzipped)...
>>>
>>> Can this still be fixed? This would break existing implementations that
>>> already use both options, though. Alternatively, is there a clean
>>> workaround? As the save(OutputStream, Map) method from ResourceImpl is
>>> final, I cannot override this behavior in my custom resource class :(
>>>
>>> Kind regards,
>>>
>>> Koen
>>>
>>>
>
>

--------------090508070707060108040607
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Koen,<br>
<br>
Comments below.<br>
<br>
Koen Yskout wrote:
<blockquote cite="mid:iae4jq$na8$1@news.eclipse.org" type="cite">
<pre wrap="">Ed,

I'm not sure I understand your reply; I assume the goal of OPTION_ZIP is
not to obtain a valid zip file, but to reduce the size of the file (at
least, that's how I want it to work :p).
</pre>
</blockquote>
It is intended to produce something that can be unzipped, but I'm not
sure that was such an important goal, <br>
<blockquote cite="mid:iae4jq$na8$1@news.eclipse.org" type="cite">
<pre wrap="">
A good symmetric crypto algorithm leaves no redundancy in its outcome
and (approximately) preserves the size of the input. So if the contents
is encrypted before it is zipped, the zipping has no effect on the size
and is pointless. This is how the current implementation seems to work.

Alternatively, first zipping would give a smaller input to encrypt, and
*does* result in a smaller file. Of course, the resulting file is then
an encrypted binary blob and not a valid zipfile; the zip only appears
after decryption. I don't see a problem with this, though.
</pre>
</blockquote>
No, I guess that would be okay.<br>
<blockquote cite="mid:iae4jq$na8$1@news.eclipse.org" type="cite">
<pre wrap="">
To illustrate, I did some experiments (using the AES cipher):

* no save options ==&gt; 18 Kb [ plain ]
* only OPTION_ZIP ==&gt; 1.4 Kb [ zip(plain) ]
* only OPTION_CIPHER ==&gt; 18 Kb [ encrypt(plain) ]
* OPTION_CIPHER and OPTION_ZIP ==&gt; 18 Kb [ zip(encrypt(plain)) ]
^- this is what the current implementation gives
* ??? ==&gt; 1.5 Kb [ encrypt(zip(plain)) ]
^- this is what I want (currently obtained using command line)

Maybe a new option (e.g., OPTION_COMPRESSED_BEFORE_CIPHERED [Boolean])
is a backwards-compatible extension that can enable this behavior?
</pre>
</blockquote>
Yes, we'd not want to break people.&nbsp; Though you have to wonder if they
were doing something pointless...<br>
<blockquote cite="mid:iae4jq$na8$1@news.eclipse.org" type="cite">
<pre wrap="">
Koen



On 28/10/10 23:53, Ed Merks wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Koen,

It wouldn't be a valid zip file if it was encrypted the other way...


Koen Yskout wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi,

As mentioned before in this newsgroup, and in bug 261620
(<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=261620">https://bugs.eclipse.org/bugs/show_bug.cgi?id=261620</a>) which was marked
as 'verified fixed' a while ago, zipping should happen before
encryption; otherwise the zipping has no effect. Nevertheless, when I
use OPTION_ZIP and OPTION_CIPHER simultaneously, the file is encrypted
first, and then zipped (the resulting file starts with 'PK', and can be
unzipped)...

Can this still be fixed? This would break existing implementations that
already use both options, though. Alternatively, is there a clean
workaround? As the save(OutputStream, Map) method from ResourceImpl is
final, I cannot override this behavior in my custom resource class :(

Kind regards,

Koen

</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</body>
</html>

--------------090508070707060108040607--
Previous Topic:Retrieving the registered packages from the ECore
Next Topic:How to draw a SWT composite in a GEF container shape and diagram
Goto Forum:
  


Current Time: Mon Oct 14 16:01:19 GMT 2019

Powered by FUDForum. Page generated in 0.02003 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top