Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 06 Aug 2012 20:38:36 +0200
From: magnum <>
To: Pavel Semjanov <>
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 ( 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!


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.