[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4630edbebb888c2dda13d82dde36fd60@smtp.hushmail.com>
Date: Mon, 06 Aug 2012 20:38:36 +0200
From: magnum <john.magnum@...hmail.com>
To: Pavel Semjanov <pavel@...janov.com>
CC: john-dev@...ts.openwall.com
Subject: Re: Patch for pkzip_fmt_plug.c from jumbo-6
On 2012-08-06 14:15, Pavel Semjanov wrote:
>> On 2012-07-27 11:10, Pavel Semjanov wrote:
>>> Hello,
>>>
>>> I've tested and fixed some errors (one is severe, the code was
>>> not working on some files!) in function check_inflate_CODE1().
>>> The patch is attached.
>>>
>>
>> Pavel,
>>
>> Thanks, this is really appreciated! Could you possibly supply test
>> files showing the problem? This would make our audit a lot easier
>> and faster.
>
> I've attached two files. The first one (future.zip) has a false early
> reject. The second one passes ok early reject, but only by accident -
> it has end-of-block marker in the first 8 bytes, so the logic of the
> function is wrong.
Both of the files are plain archives without encryption. Maybe you sent
the wrong ones?
>> BTW, could you by any chance help us with better early rejection
>> in the RAR format? I'm just asking :)
>
> It's quite simple. In CPU code, the block is checked for LZ type or
> PPM type. If it's LZ, the Huffman table test is used, like ZIP does.
Thanks! So I can pre-test it more or less exactly like pkzip do? I
thought there would be differences between LZ2 and LZ. Does cRARk do
this fairly similar to Jim's pkzip code?
Regardless, I think I'll need Jim's help here.
> If it's PPM, the reset bit should be set and MaxMB size can't be
> grather than 7f. If yes, the decompression begins and password is
> rejected quite fast in RAR PPM code.
OK. So that is what, 9 bits in total? Then I can reject 75% [of PPM]
without even calling rar_unpack29(), right?
> In GPU code, only standard parameters (i.e, -m0 .. -m5) are allowed.
> This makes very effective early reject by checking MaxOrder and MaxMB
> sizes.
I suppose I should transfer a portion of the file to GPU so I can reject
immediately. Hm, but then I'd need to implement AES on GPU too. I am
very impressed with how cRARk is totally immune against file size. But
I'll try to implement this without changing my Key-derivation-only
kernel, as a first step.
I'll try this soon, lots of thanks!
magnum
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.
