Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 17 Aug 2012 15:01:06 +0200
From: magnum <>
Subject: Re: RAR early reject

On 2012-08-17 14:38, wrote:
> Is this new quick check logic, better done on cpu, and then only
> candates that fail to be elinated, get worked on in the GPU?

The GPU currently only calculates key & IV from a candidate + salt. If I
implement AES on GPU too, I could do these early rejects there but I
doubt it would be of benefit. The best thing would be to have GPU and
CPU working at the same time.

The full inflate just can't be done on GPU. It would be terribly slow.

Even with this non-optimised code, I see almost no slowdown from
cracking a huge file versus attacking a -hp file (with only 16 bytes of
known plain-text to decrypt, no inflate at all).

> For pkzip, we had the 'checksum'  that eliminated a WHOLE lot.  I do not
> remember what the quick check elimiated, but I think it was about 90% or
> more.  With a 2 byte checksum, it was pretty rare for pkzip to do a FULL
> test at all.

There is no checksum in RAR. I also can not use these (not present):

    if (257+(hold&0x1F) > 286) return 0;  // nlen, but we do not use it.

    if(1+(hold&0x1F) > 30) return 0;  // ndist, but we do not use it.

But instead, I have a larger table if I get things right, so I suppose
that makes my table check much more effective in itself.

Also, I can check two bits before even calling your function. I now
suspect there is a third bit I can use (I have tested over 100,000 files
and that bit is NEVER set in the *first* block, which is what we look at).

All in all, I now reject over 96% without even starting a full deflate,
and the beauty is the full deflate ALSO can reject semi-early in a lot
of cases. I'm not yet sure of the "total" figures (or even how to define


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.