commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bear Giles <bgi...@coyotesong.com>
Subject Re: [commons-compress] traditional zip encryption patch to come
Date Tue, 16 Feb 2016 16:14:37 GMT
I can create test files. (I still need to create some PKWare test files as
well...). I also need to figure out a way to extract the encrypted content
to I can verify my implementation of the crypto logic itself. I think that
will just require disabling any check for the 'encrypted' bit.

​Source at
https://github.com/beargiles/commons-compress/blob/traditional-encryption/src/main/java/org/apache/commons/compress/archivers/zip/TraditionalZipEncryption.java
.

Test at
https://github.com/beargiles/commons-compress/blob/traditional-encryption/src/test/java/org/apache/commons/compress/archivers/zip/TraditionalZipEncryptionTest.java
​

​Bear​



On Tue, Feb 16, 2016 at 9:08 AM, Stefan Bodewig <bodewig@apache.org> wrote:

> On 2016-02-15, Bear Giles wrote:
>
> > We discussed adding support for the traditional zip encryption algorithm
> a
> > while back. IIRC the concensus was loosely against it since it's so weak
> > and we don't want to mislead people.
>
> I'm pretty sure we should ad a big warning about the quality of
> encryption to expect, but there are good reasons to implement decryption
> - and not quite so good reasons for encryption, too :-)
>
> > Second, I've been looking at the strong encryption algorithms (WinZip and
> > the un-distributable PKWare) and they'll need some way to insert
> encryption
> > and decryption into the ZIP streams. The traditional approach may
> > illustrate problems we can expect with WinZip strong encryption.
>
> True. Even though WinZip strong encryption will need a different
> approach as it is a "method" of its own rather than used in addition to
> one of the other methods.
>
> > My approach is to create two Filter classes -
> > TraditionalZipEncryptionInputStream and
> > TraditionalZipEncryptionOutputStream - and inject them at the lowest
> level.
>
> > There are two problems that prevent this from being completely
> transparent.
>
> > First, the ciphertext is precisely 12 bytes larger than the plaintext due
> > to the presence of an encrypted salt. I know that ZipEntry has a
> > 'compressed size' field that's used with reading and skipping the actual
> > stream but I don't know if the decompression logic uses an internal EOF
> > marker or if it uses the number of bytes. This might cause problems and I
> > don't want to make any assumptions.
>
> Without encryption you get both flavors. DEFLATE uses an internal
> marker, STORED uses the number of bytes, for example. From looking
> through appnote I don't see a definitive answer, we should probably look
> at real world archives.
>
> > Second, the algorithm requires the CRC of the original data. The last
> byte
> > of the encrypted salt should be the same as the low byte of the CRC. If
> not
> > it's assumed that the provided password is incorrect. (If it matches
> > there's still a remote chance that it's incorrect but overall we can
> save a
> > lot of wasted effort.) This isn't an issue in streaming mode - just use
> 0 -
> > but it requires a way to get that value to the constructor when the
> header
> > value is not 0.
>
> We may even run into a situation - when writing to a RandomAccessFile -
> where we move back to write the CRC into the header after we've written
> the file's contents. This would likely require us to calculate the CRC
> before actually starting to encrypt the data.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

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