Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 09 Aug 2012 01:57:49 +0200
From: magnum <>
CC: Pavel Semjanov <>
Subject: Re: Patch for pkzip_fmt_plug.c  from jumbo-6

On 2012-08-08 23:36, Pavel Semjanov wrote:
>> Both of the files are plain archives without encryption. Maybe you sent
>> the wrong ones?
> I've just explained why I can't to it in previous message.

I see, I thought you had encrypted files too.

>>> 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?
> Hmm... 3 bits, right? One for PPM, one for reset, one for MaxMB. So, 7/8
> of passwords can be rejected.

Right. I meant I was not sure about the size of MaxMB - if it had been
eg. a 16 bit field, we could reject a lot more. It seems to be an 8 bit
field so given we have a PPM block we can look at two more bits and
reject 3/4.

>> In GPU code, only standard parameters (i.e, -m0 .. -m5) are allowed.
>> This makes very effective early reject by checking MaxOrder and MaxMB
>> sizes. 

Do you mean there is more to check in MaxOrder than the reset bit?


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.