Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 4 Sep 2020 01:30:50 +0200
From: Solar Designer <>
Subject: Re: rar-opencl performance

On Fri, Sep 04, 2020 at 01:18:56AM +0200, Axymeus wrote:
> cRARk goes up to 20K p/s on this archive.

This can mean one of several things:

1. cRARk handles the archive smarter, rejecting candidate passwords
earlier.  We do have early-reject in many cases, but apparently not
working as effectively in yours.  If this is the case, then it's
something magnum (a JtR developer) will want to improve in our
rar-opencl format, I guess.  You might want to provide to him a copy of
the archive - or preferably another "equivalent" archive with a known
password and no sensitive content.

2. cRARk handles the archive incorrectly, rejecting candidate passwords
early too aggressively, and might produce false negatives (miss the
correct password).

3. cRARk implements full archive processing on GPU now - probably not
the case.

I guess #1 is most likely the case.

What GPU utilization do you observe when cRARk is running on this
archive?  And CPU too?  This might give us a hint.


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.