commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bear Giles <>
Subject Re: [COMPRESS] pkware header id for crypto extensions
Date Mon, 21 Sep 2015 13:53:12 GMT
I have a moment to explain why the PKWARE crypto is stronger than the
WinZip crypto.

1. The key has validation data, the VData and VCRC32 values.

There are a couple different ways to compute a message integrity check that
allows you to verify the encryption key and that the message contents have
not been modified. This is only available after encrypting all of the data
- in streaming mode this information would have to be written to a footer.
That's not difficult but it means that something has been written to the
disk before it's verified and that might cause problems.

Message integrity checks also require maintenance of a second key that's
independent of the first. Some ciphers have an encryption mode that handles
message integrity at the same time it does decryption but many ciphers do
not and you can't assume all readers supports those ciphers and modes.

Key validation won't detect message corruption but the file CRC gives us a
modest level of protection. It's only modest though since it's easy to set
the message CRC to whatever value you want if you can modify 4 bytes.
That's impractical with a true HMAC with strong algorithms.

2. Encrypted random data (ERD)

You can often predict the initial contents of a file from the filename
extension. For instance a .xml file probably starts with <?xml
version="1.0"?> or the compressed version of the same. This means you have
a "known plaintext" problem and it is a powerful tool used to break the
legacy ZIP encryption.

ERD handles that by prepending random data to the file. The reader knows to
ignore those bytes. The ERD is encrypted in the header with the same key
(but all-zero IV?) to avoid the same "known plaintext" problem.

One of the WW-II (or WW-I?) German ciphers was broken this way. Messages
were supposed to start with a unique value but one clerk repeated one by
accident. It was enough to break the cipher since all messages started the
same way.


On Sun, Sep 20, 2015 at 8:36 PM, Bear Giles <> wrote:

> I took out some debugging scaffolding so you can check it out. One of the
> unit tests fails but it should since it's trying to read an archive with an
> encrypted CD. (I haven't gotten around to wrapping it with an exception
> handler that fails if an exception isn't thrown.)
> Theoretically you can do a pull request. I think.
> Bear
> On Tue, Sep 15, 2015 at 8:03 AM, Stefan Bodewig <>
> wrote:
>> On 2015-09-14, Bear Giles wrote:
>> > I want to capture as much information as possible but the documentation
>> is
>> > a weird mixture of details and hand-waving. Some is detailed, some is
>> > "compatible with the format used by the Microsoft CRYPTOAPI".  How is
>> > anyone supposed to use that if all they have is the APPNOTE.txt file?
>> Compared to some other "specs" we implement, this is brilliant ;-)
>> > Anyway I can demonstrate that the headers are recognized in at least one
>> > test case so I'll just remove the debugging code and add a few getters.
>> Sounds great.
>> > FWIW my initial impression from what's in the fields is that WinZip is
>> > competently implemented but PKWare is a LOT more solid. I can give
>> details
>> > if anyone wants to be bored. :-)
>> Expect me to ask you for the boring details once I start breathing
>> again.  Probably better off-list :-)
>> Cheers
>>         Stefan
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

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