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:10:50 +0200
From: Solar Designer <>
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?


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.