(Not an OpenJDK reviewer) Hi,
I was wondering if the CRC32 implementation in TraditionalZipCryption could be replaced with java.util.zip.CRC32 class. Though I note that in this case TraditionalZipCryption#updateKeys(int c) will require CRC32#update(int crc, int b) method which is currently marked as private. Maybe its access specification could be relaxed a little to be package-private? Regards, Anirvan On 16 December 2015 at 20:17, Yasumasa Suenaga <yasue...@gmail.com> wrote: > 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.s...@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.y...@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 >>>>>>>> >>>>>>> >>>>>> >>>>>> >> >> -- Anirvan
