Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 11 Sep 2011 20:03:57 +0200
From: magnum <>
Subject: Re: Rewrite of the pkzip format posted (on the wiki).

On 2011-09-11 00:52, magnum wrote:
> Both of the tests affected in the enclosed patch clearly gave false
> negatives on However, there *might* be
> better ways than just commenting them out like I did. In this case, C
> was 80 (decimal) in the first test and v1 was 0x034b while v2 was 0x1404
> (v2^0xffff was 0xebfb). We might be able to put these back with some
> correction for what is valid or not. If not, there are some more code
> that should be commented out 'cause it's currently unnecessary.
> OTOH I don't see much of a performance hit. But I do not possess any
> 1-byte checksum zipfiles. These checks are the fourth and fifth so lots
> of false positives are already sorted.

I realised I could hack my infiles so they use a 1-byte checksum, for 
testing. The test file was 2.5 MB uncompressed.

With the offending early tests in place, 1-byte or 2-byte checksums run 
almost the same speed. With the tests disabled, 1-byte checksum runs a 
couple percent slower, but there is still not a single full decryption + 
decompression made for a false positive. My test ran --inc:digits to 
completion so there were >100 million candidates tried. The remaining 
tests rejected every one of the false positives semi-early. Good stuff!


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.