[PING] PoC for JDK-4347142: Need method to set Password protection to Zip entries

Xueming Shen xueming.shen at oracle.com
Sun Dec 20 07:35:30 UTC 2015 

You Yasumasa,

It is no longer necessary to touch the native code (zip_util.c/h) after the
native ZipFile implementation has been moved up to the java level. Those
native code are for vm access only now, which I dont think care about the
password support at all.

But before getting into the implementation details, it might be worth having
some design discussion first. Here are some questions we can start the
discussion.

(1) what's the benefit of exposing the public interface ZipCryption? the 
real
question is whether or not this interface is good enough for other 
encryption
implementation to plugin their implementation to support the ZipFile/Input/
OutputStream to their encryption spec.

(2) it seems like it might be possible to hide most of the 
implementation and
only expose the "String password" (instead of the ZipCryption) as the public
interface to support the "traditional" encryption. This depends on the 
result
of (1) though.

(3) I'm concerned of pushing ZipCryption into 
InflaterInputStream/DeflaterOutputStream.
It might be worth considering to replace the ZipCryption implementation with
a pair of FilterOutput/InputStream. It would be easy and reasonable to 
use the
FilterOutputStream for the ZipOutputStream and the FilterInputStream for the
ZipFile. The PushbackInputStream in ZipInputStream might be an issue ...

(4) It seems the ZipOutputStream only supports the "stream based" 
password, while
the ZipInputStream  supports the "entry based" password. Do we really need
"entry based" support here?

-Sherman

On 12/17/15, 9:45 PM, Yasumasa Suenaga wrote:
> Hi Jason,
>
> Thank you for your comment.
> I've fixed it in new webrev:
>   http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.03/
>
>
> Thanks,
>
> Yasumasa
>
>
> On 2015/12/17 0:33, Jason Mehrens wrote:
>> The null check of 'entry' at line 351 of ZipFile.getInputStream  is 
>> in conflict with line 350 and 348.
>>
>> ________________________________________
>> From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> on 
>> behalf of Yasumasa Suenaga <yasuenag at gmail.com>
>> Sent: Wednesday, December 16, 2015 8:47 AM
>> To: Sergey Bylokhov; Xueming Shen
>> Cc: core-libs-dev at openjdk.java.net
>> Subject: Re: [PING] PoC for JDK-4347142: Need method to set 
>> Password    protection to Zip entries
>>
>> Hi Sergey,
>>
>> Thank you for your comment.
>>
>> I added that description in new webrev:
>>     http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.02/
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> On 2015/12/16 22:19, Sergey Bylokhov wrote:
>>> Should the new methods describe how they will work in case of null 
>>> params?
>>>
>>> On 16/12/15 16:04, Yasumasa Suenaga wrote:
>>>> I adapted this enhancement after JDK-8145260:
>>>>     http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.01/
>>>>
>>>> Could you review it?
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Yasumasa
>>>>
>>>>
>>>> On 2015/12/12 21:23, Yasumasa Suenaga wrote:
>>>>> Hi Sherman,
>>>>>
>>>>> Our proposal is affected by JDK-8142508.
>>>>> We have to change ZipFile.java and and ZipFile.c .
>>>>> Thus we will create a new webrev for current (after 8142508) jdk9/dev
>>>>> repos.
>>>>>
>>>>> Do you have any comments about current webrev?
>>>>>     http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/
>>>>>
>>>>> If you have comments, we will fix them in new webrev.
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Yasumasa
>>>>>
>>>>>
>>>>> On 2015/12/03 16:51, KUBOTA Yuji wrote:
>>>>>> Hi Sherman,
>>>>>>
>>>>>> Thanks for your quick response :)
>>>>>>
>>>>>> I aimed to implement the "traditional" at this proposal by the below
>>>>>> reasons.
>>>>>>
>>>>>>    * We want to prepare API for encrypted zip files at first.
>>>>>>      * Many people use the "traditional" in problem-free scope 
>>>>>> like a
>>>>>> temporary file.
>>>>>>    * We do not know which implementation of the "stronger" is 
>>>>>> best for
>>>>>> openjdk.
>>>>>>      * PKWare claims that they have patents about the "stronger" on
>>>>>> Zip[1].
>>>>>>      * OTOH, WinZip have the alternative implementation of the
>>>>>> "stronger" [2][3].
>>>>>>    * Instead, we prepared the extensibility by ZipCryption 
>>>>>> interface to
>>>>>> implement other encrypt engine, such as the AES based.
>>>>>>
>>>>>> Thus, I think this PoC should support the "traditional" only.
>>>>>> In the future, anyone who want to implement the "stronger" can 
>>>>>> easily
>>>>>> add their code by virtue of this proposal.
>>>>>>
>>>>>> [1] https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.3.TXT
>>>>>>       (1.4 Permitted Use & 7.0 Strong Encryption Specification)
>>>>>> [2]
>>>>>> https://en.wikipedia.org/wiki/Zip_(file_format)#Strong_encryption_controversy 
>>>>>>
>>>>>>
>>>>>> [3] http://www.winzip.com/aes_info.htm
>>>>>>
>>>>>> Thanks,
>>>>>> Yuji
>>>>>>
>>>>>> 2015-12-03 12:29 GMT+09:00 Xueming Shen <xueming.shen at oracle.com>:
>>>>>>>
>>>>>>> Hi Yuji,
>>>>>>>
>>>>>>> I will take a look at your PoC.  Might need some time and even 
>>>>>>> bring
>>>>>>> in the
>>>>>>> security guy
>>>>>>> to evaluate the proposal. It seems like you are only interested 
>>>>>>> in the
>>>>>>> "traditional PKWare
>>>>>>> decryption", which is, based on the wiki, "known to be seriously
>>>>>>> flawed, and
>>>>>>> in particular
>>>>>>> is vulnerable to known-plaintext attacks":-) Any request to support
>>>>>>> "stronger" encryption
>>>>>>> mechanism, such as the AES based?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Sherman
>>>>>>>
>>>>>>>
>>>>>>> On 12/2/15 6:48 PM, KUBOTA Yuji wrote:
>>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> We need reviewer(s) for this PoC.
>>>>>>>> Could you please review this proposal and PoC ?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Yuji
>>>>>>>>
>>>>>>>> 2015-11-26 13:22 GMT+09:00 KUBOTA Yuji <kubota.yuji at gmail.com>:
>>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> * Sorry for my mistake. I re-post this mail because I sent 
>>>>>>>>> before get
>>>>>>>>> a response of subscription confirmation of core-libs-dev.
>>>>>>>>>
>>>>>>>>> Our customers have to handle password-protected zip files. 
>>>>>>>>> However,
>>>>>>>>> Java SE does not provide the APIs to handle it yet, so we must 
>>>>>>>>> use
>>>>>>>>> third party library so far.
>>>>>>>>>
>>>>>>>>> Recently, we found JDK-4347142: "Need method to set Password
>>>>>>>>> protection to Zip entries", and we tried to implement it.
>>>>>>>>>
>>>>>>>>> The current zlib in JDK is completely unaffected by this 
>>>>>>>>> proposal.
>>>>>>>>> The
>>>>>>>>> traditional zip encryption encrypts a data after it is has been
>>>>>>>>> compressed by zlib.[1] So we do NOT need to change existing zlib
>>>>>>>>> implementation.
>>>>>>>>>
>>>>>>>>> We've created PoC and uploaded it as webrev:
>>>>>>>>>
>>>>>>>>>        
>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/
>>>>>>>>>
>>>>>>>>>        Test code is as below. This code will let you know how 
>>>>>>>>> this PoC
>>>>>>>>> works.
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/Test.java 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> In NTT, a Japanese telecommunications company. We are 
>>>>>>>>> providing many
>>>>>>>>> enterprise systems to customers. Some of them, we need to
>>>>>>>>> implement to
>>>>>>>>> handle password-protected zip file. I guess that this proposal is
>>>>>>>>> desired for many developers and users.
>>>>>>>>>
>>>>>>>>> I'm working together with Yasumasa Suenaga, jdk9 committer
>>>>>>>>> (ysuenaga).
>>>>>>>>> We want to implement it if this proposal accepted.
>>>>>>>>>
>>>>>>>>> [1]: 
>>>>>>>>> https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.3.TXT
>>>>>>>>> (6.0  Traditional PKWARE Encryption)
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Yuji
>>>>>>>
>>>>>>>
>>>
>>>

More information about the core-libs-dev mailing list