Hi Anirvan, j.u.z.CRC32 supports 8-bits value and byte array. update(int, int) which you suggested will calculate lower 8-bits value:
http://docs.oracle.com/javase/8/docs/api/java/util/zip/CRC32.html#update-int - http://hg.openjdk.java.net/jdk9/dev/jdk/file/a204b8e18d46/src/java.base/share/classes/java/util/zip/CRC32.java#l58 http://hg.openjdk.java.net/jdk9/dev/jdk/file/a204b8e18d46/src/java.base/share/native/libzip/CRC32.c#l36 Thus this method cannot fit our purpose - we need calculate 32-bits value. If we use j.u.z.CRC32, we also have to add new API to it. Thanks, Yasumasa 2015/12/17 13:40 "Anirvan Sarkar" <powers.anir...@gmail.com>: > (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 >
