[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 4 Sep 2020 01:10:50 +0200
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: rar-opencl performance
On Fri, Sep 04, 2020 at 12:51:24AM +0200, Axymeus wrote:
> As you can see the performance is only marginally better in phase 3
[...]
> Proceeding with incremental:ASCII
> 0g 0:00:04:48 3/3 0g/s 1220p/s 1220c/s 1220C/s jaith..murtos
> 0g 0:00:05:32 3/3 0g/s 1183p/s 1183c/s 1183C/s bakku..mysey
> 0g 0:00:06:24 3/3 0g/s 1183p/s 1183c/s 1183C/s saluke..mynen1
> 0g 0:00:08:06 3/3 0g/s 1145p/s 1145c/s 1145C/s bordaku..miamm1
> Session aborted
>
> However running rar-opencl with -test gives... 46704 c/s real, 46811
> c/s virtual (Benchmarking: rar-opencl, RAR3 (length 5) [SHA1 OpenCL
> AES]... (12xOMP))
OK. Then I suspect it's the specifics of your RAR archive and/or
storage method (compressed or not) of the file inside archive that's
being attacked. In some cases, the whole data needs to be decrypted or
even uncompressed before a candidate password can be rejected. This is
done on CPU, which is why the GPU load would be low.
What performance are you getting when using cRARk on this archive?
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.
