Home » Modeling » EMF » Zip & encrypt resource
| Zip & encrypt resource [message #635894] |
Thu, 28 October 2010 14:11  |
Eclipse User |
|
|
|
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  |
 Ed Merks
Messages: 33142
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
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Zip & encrypt resource [message #636095 is a reply to message #636005] |
Fri, 29 October 2010 09:40 |
| Eclipse User |
|
|
|
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 |
Ed Merks
Messages: 33142
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 ==> 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?
</pre>
</blockquote>
Yes, we'd not want to break people. 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--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Apr 26 12:06:59 GMT 2024
Powered by FUDForum. Page generated in 0.03718 seconds |
] 
Search
Help
Register
Login
Home
