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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
