commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bear Giles <bgi...@coyotesong.com>
Subject [compress] Support for strong encryption in zip files?
Date Wed, 12 Jun 2013 00:03:27 GMT
What is the status on strong encryption in zip files? That is - I know we
don't have it, but is there a reason why it hasn't been added or is it just
an itch that hasn't been scratched?

I can see several levels of values

1. add ZipExtraField handlers for the five extra fields of interest (0x14,
0x15, 0x16, 0x17, 0x19) even if encryption/decryption isn't supported. It
could still provide useful information, e.g., identifying users able to
decrypt the file.
2. add read-only support.
3. add write support.

The last two items can be further split by password and X.509 certificate.
The latter is particularly interesting since it means you can have an
unprivileged user create an encrypted archive without having to reveal the
password.

The two potential issues I've found so far are 1) export/import
restrictions that may limit functionality and 2) language in the PKWARE
documentation at http://www.pkware.com/documents/casestudies/APPNOTE.TXT.

I think the first point is easily handled since it can and should be punted
to the user's configuration. The default configuration is designed to be
legal everywhere and the user (even US domestic users) must take explicit
action to enable stronger encryption.

On the second point the language is:

7.0 Strong Encryption Specification
-----------------------------------

   7.0.1 Portions of the Strong Encryption technology defined in this
   specification are covered under patents and pending patent applications.
   Refer to the section in this document entitled "Incorporating
   PKWARE Proprietary Technology into Your Product" for more information.


10.0 Incorporating PKWARE Proprietary Technology into Your Product
------------------------------------------------------------------

   10.1 The Use or Implementation in a product of APPNOTE technological
   components pertaining to either strong encryption or patching requires
   a separate, executed license agreement from PKWARE. Please contact
   PKWARE at zipformat@pkware.com or +1-414-289-9788 with regard to
   acquiring such a license.

   10.2 Additional information regarding PKWARE proprietray technology is
   available at http://www.pkware.com/appnote.


I don't know if this is outdated language, if it's a pro forma
request, if Apache commons already has a license agreement, if Apache
commons won't use it as a matter of principle, etc.

--- Legacy Encryption ---

A related question involves support for the legacy encryption. It's
easily cracked but people might need to read old encrypted files. It's
even possible that some people may still be forced to use it because
of contractual obligations.

I will resist the temptation to offer a flag to make the decryption
key optional.

Bear

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message