[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK_fNXSkRN69oZazp_rjGbZ+pBmx-ujKpW9WfomJichSPaGNYA@mail.gmail.com>
Date: Mon, 7 Sep 2020 17:37:38 +0200
From: Axymeus <axymeus@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: rar-opencl performance
Can't find unrar, not even within cygwin, where should I get it?
The archive does contain a single large file (~300 MB)
On Sat, Sep 5, 2020 at 9:17 PM magnum <john.magnum@...hmail.com> wrote:
>
> On 2020-09-04 10:02, Solar Designer wrote:
> > On Fri, Sep 04, 2020 at 01:50:02AM +0200, Axymeus wrote:
> >> Alright, looks like Windows 10 is not properly reporting GPU usage
> >> when running a PowerShell command... Looking at Afterburner I can see
> >> that both cRARk and JTR are actually using 100% GPU, but not
> >> constantly. There's a brief spike and a brief pause, but a much longer
> >> pause between each spike with JTR. CPU usage is about the same. Here
> >> is a visual comparison https://i.imgur.com/gIOBKeA.jpg on the left of
> >> the graph usage cycle of cRARk and on the right usage cycle of JTR.
> >
> > OK, so it's possibilities 1 or 2, but not 3. (Of those I listed below.)
> >
> >> Unfortunately I won't be able to provide the archive being used. And
> >> I'm not sure how to produce an equivalent, but I could give it a shot.
> >
> > magnum, do you have any advice for Axymeus on what parameters of the
> > archive to look up and how, and how to replicate those?
>
> Axymeus, please post the result of "unrar vt <archive name>". My guess
> is this is a very large "stored" file. I believe cRARk will process
> such files fully on GPU if possible, while we will not - as of now. We
> could definitely implement that, I just never considered it worthwhile
> because it's so uncommon.
>
> Thanks,
> magnum
>
> >> On Fri, Sep 4, 2020 at 1:31 AM Solar Designer <solar@...nwall.com> wrote:
> >>>
> >>> 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.
> >>>
> >>> Alexander
> >
>
>
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.
