[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <09326e6987de3959b8ed18db301f34d4@smtp.hushmail.com>
Date: Thu, 09 Aug 2012 01:57:49 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
CC: Pavel Semjanov <pavel@...janov.com>
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?
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.
