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.s...@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"<yasue...@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.
