Encrypted zip support

[kwrobot]

Original issue 78 created by jsonn on 2010-03-14T20:32:10.000Z:

Encrypted entries should be have the same flags in the entry as in the
directory. It should therefore be possible to supported encrypted entries.

This needs extensions to the libarchive API for passing down / querying the
password.

[kwrobot]

Comment #1 originally posted by kientzle on 2010-03-14T21:23:55.000Z:

I would suggest handling passwords through an option, e.g.,
  --option password=357X8&4z
That will easily extend to other formats.  Though we may need to rethink the options
API somewhat; the current API wouldn't allow commas in passwords.  Maybe the internal
API should only permit a single option at a time instead of trying to support
comma-separated lists of options?  If we need to make that change, 3.0 is our chance.

[kwrobot]

Comment #2 originally posted by jsonn on 2010-03-14T21:48:39.000Z:

An option is bad as it is visible to other users on many systems. I also don't think
it makes sense from a user-perspective to require knowing in advance that something
in an archive is encrypted.

I can think of two interface extensions to deal with this kind of problem:

archive_read_set_password(struct archive *, void *, size_t)
archive_read_set_password_callback(struct archive *, int (*)(void *, struct
archive_entry *, void **, size_t *), void *)

The former would cover the case of an explicit --password option (or
--password-file), the latter would allow a callback for interactive use.

[kwrobot]

Comment #3 originally posted by Google Code user rransom.8774 on 2010-03-14T23:11:54.000Z:

To properly support Zip archives with encrypted entries, the archive read API must 
support multiple cryptographic keys:

struct archive_key {
  void *key;
  size_t *key_bytes;
  int key_type;
};

#define ARCHIVE_KEY_TYPE_RAW_KEY 0
#define ARCHIVE_KEY_TYPE_PASSWORD 1

int archive_read_add_key(struct archive *, struct archive_key *);



When writing an archive, encryption keys may need to be directed to specific archive 
entries (in the Zip format) or filters (with any archive format).

[kwrobot]

Comment #4 originally posted by jsonn on 2010-03-14T23:43:33.000Z:

I'm not concerned about writing them ATM -- at least for zip files the default
encryption mechanism is more about obscurity than security and not something I really
consider useful.

For reading the common case of a single password is covered by the first approach and
if you need anything more complex, use the callback. I think that's fine. Policies
like asking at most three times for the same entry can be implemented in the callback
easily.

[kwrobot]

Comment #5 originally posted by kientzle on 2010-03-15T04:54:56.000Z:

> archive_read_set_password(struct archive *, void *, size_t)

This can be handled as
  archive_read_set_options(struct archive *, "password=XXXX");
there's no need for another option.
Being able to set an option value from a file might be an interesting
general feature.

I'm not a big fan of the callback approach (despite evidence
to the contrary ;-).  If libarchive had better error management,
we could maybe handle password requirements by returning a
"PASSWORD_REQUIRED" error and allowing the client to try
again.  But this isn't easy to integrate into the existing
framework, so a callback may be the best we can do.  <sigh>

[kwrobot]

Comment #6 originally posted by kientzle on 2011-11-23T09:23:21.000Z:

Note:  The recent addition of a seek-based Zip reader should make this much easier, since that reader has full access to the extended Zip fields stored in the Central Directory.

[kwrobot]

Comment #7 originally posted by Google Code user mtomasz@chromium.org on 2014-07-23T03:42:23.000Z:

Any plans to add this feature anytime soon?

[kwrobot]

Comment #8 originally posted by kientzle on 2014-07-23T05:51:33.000Z:

I do not know of anyone working on this feature right now.

[kwrobot]

Comment #9 originally posted by Google Code user konrad.wilhelm.kleine on 2014-07-23T07:44:44.000Z:

Hi, I've implemented the encryption detection support in libarchive and I might start working on this as soon as I have made progress with the integration of the UnRAR library for future proof and maintainable RAR support. But I need more time for this.

In my opinion, there's no other option but to implement a callback because you can have an archive with files in it that were encrypted using different passwords. At least in RAR you can do this. If you don't want to use a callback it would require you to pass in a list of passwords. Then all you could do is try decryption with all the passwords in your list. For big files this trial and error approach can possibly slow things down quite significantly.

[kwrobot]

Comment #10 originally posted by Google Code user DaGoodBoy on 2014-12-04T19:21:20.000Z:

I understand the goal would be to decrypt the archived data, but at the very least it would be nice to have a standard flag or error code to indicate an archive is encrypted.

I'd like to use libarchive as a library to handle unknown archive data and there's no way to differentiate between an archive that is corrupt and one that is encrypted.

For example, password protected zip files can still be listed by the standard command line tools under Linux, but attempting to list the contents with libarchive yields a decompression failed error.

[kientzle]

I believe this is fully implemented in libarchive master.