Date: Fri, 17 Aug 2012 15:01:06 +0200 From: magnum <john.magnum@...hmail.com> To: john-dev@...ts.openwall.com Subject: Re: RAR early reject On 2012-08-17 14:38, jfoug@....net 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 it). 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.