PING: RFR: JDK-4347142: Need method to set Password protection to Zip entries

Fri Apr 15 10:03:58 UTC 2016

Hi Anthony, Sherman and all.

Anthony, thank you for your comment!

I and Yasumasa have recognized that the zipfs should be handled
as Anthony said. However, we fear to make conflict of concept /
implementation if we enhance the zipfs API now because it will be
fixed in the near future.

So I believe we should implement separately at the following steps.

 1. Add the API of "traditional encrypt" which have enough
    expandability for adding other encrypt engine as AE-1/2.
    The expandability will implement by adding a new stream
    which based on provided sample by Sherman.
 2. Add AE-1/AE-2 using as samples as Sherman's implementation.
 3. Add enhancement to support zipfs after the API of zipfs is fixed.

Instead of implementing many encryption at a time, we believe that
adding the zip encryption API with "expandability" (as a first step)
is more constructive. In addition to this, implementing "Traditional
Encryption" is meaningful because it has definitely worth in some
scene as Tomoyuki said.

For a second step, I read the WinZip document and feel that WinZip's
AE-1/AE-2 may be free from the risk I have anticipated. Although,
I feel we should confirm the pkware-winzip agreement and third-party
licensing issue with more relevant document, e.g., press release on
the agreement, etc,...
So we believe it is better not to implement them now but to leave
them and make possible to add them later.

Thanks,
Yuji

2016-04-09 1:52 GMT+09:00 Anthony Vanelverdinghe
<anthony.vanelverdinghe at gmail.com>:
> Hi Yuji, Sherman et al.
>
> PKWARE's "Strong Encryption Specification" [1] indeed warns about patents,
> but how/why does this affect Winzip's AE-1 and AE-2 [2]?
>
> I don't mind if decryption support is added for the "Traditional
> Encryption". However, I believe it would be wrong to introduce encryption
> support for a known-to-be-broken encryption method in the JDK. Using the
> argument of "it's good enough for our case", I could also argue that Base64
> qualifies as an encryption method, or that SSLv2 is an appropriate choice to
> secure network connections.
>
> However, if this is to be added, it should be supported by the zipfs
> FileSystemProvider as well. The passphrase handler could be passed by a
> property in the environment, e.g. Function<Path, Optional<String>> which
> would provide the passphrase for a given path, or Optional.empty() if the
> Path is unencrypted.
>
> Kind regards, Anthony
>
> [1] https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT
> [2] http://www.winzip.com/win/en/aes_info.htm
>
>
> On 8/04/2016 13:04, KUBOTA Yuji wrote:
>>
>> Hi Sherman and all,
>>
>> Thank you for all comments about this proposal!
>>
>> Thank Tomoyuki and Stephen for sharing your needs.
>>
>> Thank Bernd for sharing your information. However, I am
>> afraid that AE1 and AE2 may have a risk of patent issue,
>> while "Traditional PKWare encryption" is explicitly free
>> from the risk according to the PKWare documents.
>> Therefore, I think this proposed implementation to support
>> legacy zip specification is meaningful as Tomoyuki said.
>>
>> We got some positive opinions / needs. I am glad if you
>> consider the proposal acceptable for JDK.
>> If this proposed implementation is acceptable, I and
>> Yasumasa will improve it by corresponding to comments
>> which given by Sherman and Stephen.
>>
>> Thanks!
>> Yuji
>>
>> 2016-03-29 6:41 GMT+09:00 Xueming Shen <xueming.shen at oracle.com>:
>>>
>>> Yasumasa
>>>
>>> It's a tricky call. To be honest, as I said at the very beginning, I'm
>>> not
>>> sure whether
>>> or not it's a good idea and worth the efffort to push this into the
>>> j.u.zip
>>> package to
>>> support the "traditional PKWare encryption", which is known to be
>>> "seriously
>>> flawed,
>>> and in particular is vulnerable to known-plaintext attacks" (from wiki),
>>> while I fully
>>> understood it is not a concern in your "problem-free" use scenario. Just
>>> wonder
>>> if there is anyone else on the list that has/had the need for such
>>> encryption feature
>>> in the past. It would be preferred to have more input (agree, disagree)
>>> to
>>> make the
>>> final decision.
>>>
>>> Here are some comments regarding the proposed implementation,
>>>
>>> (1) The changes in native code are probably no longer needed. The native
>>> path is
>>>       left there for vm directly access.
>>> (2) I'm concerned about the footprint increase for the ZipEntry class
>>> (the
>>> proposed
>>>       change is adding 3 more fields into the entry class). Given this is
>>> something rarely
>>>       needed/used, and we might have hundreds and thousands of zip/jar
>>> entries during
>>>       startup/runtime, it might be desired to avoid adding these fields
>>> into
>>> ZipEntry class.
>>>       A possible alternative to have a dedicated entry class extended
>>> from
>>> the ZipEntry
>>>       to hold those extra fields and methods, EncryptionZipEntry for
>>> example.
>>> So the
>>>       proposed encryption support code will not have any impact to the
>>> existing use of
>>>       ZipInput/OutputStream/File.
>>> (3) I'm also not comfortable to add the "encryption engine" logic into
>>> the
>>> in/deflater
>>>       stream classes, while it might be convenient to do so from
>>> implementation point
>>>       of view. Given the encryption is something between the raw bites in
>>> the
>>> zip file
>>>       and the in/deflating layer, it might need an extra layer there,
>>> though
>>> I'm not sure
>>>       if it's easy to do so.
>>>
>>> The webrev below is what I think might be better for the ZipFile and
>>> ZipOutputStream
>>> to have an extra layer in between to handle the encryption. Not try to
>>> test
>>> if it really
>>> works, just throw in the idea for discussion.
>>>
>>> http://cr.openjdk.java.net/~sherman/zencrypt/webrev/
>>>
>>> No, I did not try the ZIS, the "pushback" stream there might be a little
>>> tricky:-)
>>>
>>> -Sherman
>>>
>>>
>>> On 03/28/2016 02:34 AM, Yasumasa Suenaga wrote:
>>>>
>>>> PING: Could you review it?
>>>> We want to move forward this enhancement.
>>>>
>>>> Thanks,
>>>>
>>>> Yasumasa
>>>> 2016/03/19 22:01 "Yasumasa Suenaga"<yasuenag at gmail.com>:
>>>>
>>>>> Hi Alan,
>>>>>
>>>>>> I think the main issue here is to decide whether the API
>>>>>> should be extended for encryption or not.
>>>>>
>>>>> We've discussed on the premise that we add the API for supporting ZIP
>>>>> encryption.
>>>>> In this context, Sherman tried to implement AES encryption extending
>>>>> current API. [1]
>>>>>
>>>>> IMHO, ZIP encryption should be implemented as extention of current ZIP
>>>>> API
>>>>> because encryption/decryption will process for each ZIP entries.
>>>>>
>>>>> According to Developers' Guide, guideline for adding new API is TBD.
>>>>> [2]
>>>>> What should I do next?
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Yasumsa
>>>>>
>>>>>
>>>>> [1]
>>>>>
>>>>>
>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/037903.html
>>>>> [2] http://openjdk.java.net/guide/changePlanning.html#api
>>>>>
>>>>>
>>>>> On 2016/03/19 0:25, Alan Bateman wrote:
>>>>>>
>>>>>> On 18/03/2016 15:02, Yasumasa Suenaga wrote:
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> We (including me and Yuji Kubota (ykubota: OpenJDK jdk9 Author))
>>>>>
>>>>> discussed
>>>>>>>
>>>>>>> about this issue from Nov. 2015. [1]
>>>>>>> We heard several comments and we applied them to our patch.
>>>>>>>
>>>>>>> I have not heard new comment for our latest patch.
>>>>>>> So I send review request for it. Could you review it?
>>>>>>>
>>>>>>>      webrev:
>>>>>>>        http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.04/
>>>>>>>
>>>>>>>      Usage of new API:
>>>>>>>
>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.04/Test.java
>>>>>>
>>>>>> Yasumasa - I think the main issue here is to decide whether the API
>>>>>> should be extended for encryption or not. If exposing it in the API
>>>>>> make
>>>>>> sense then I assume that alternative names to
>>>>>> java.util.zip.ZipCryption
>>>>>> needs to be explored.
>>>>>>
>>>>>> -Alan.
>>>>>>
>