[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4D301A6E.2090108@banquise.net>
Date: Fri, 14 Jan 2011 10:42:06 +0100
From: Simon <simon@...quise.net>
To: john-users@...ts.openwall.com
Subject: Re: opencl sha1 jtr and others some experiments
On 14/01/2011 10:17, Milen Rangelov wrote:
> 2) You can almost completely get rid of slow device-to-host PCIe transfers
> by doing the checks in the kernel code. It is rather easy if you check a
> single hash, it gets much harder if you check against a number of hashes. In
> the latter case, different tricks can be employed, however you'll likely
> need to access slow global memory. If you need to write a fast GPU cracker,
> you will have to get rid of the transfers anyway as the PCIe bandwidth
> limits the maximum speed (e.g PCIe 2 has 8GB/s bandwidth or ~ 500 million
> MD5 c/s as theoretical maximum, however even with pinned memory you're
> unlikely to even get somewhere near that). And modern ATI GPUs like e.g 5870
> are capable of doing more than 3 billion MD5 ops/sec). For SHA1 it gets even
> worse as the digest size is somehow larger.
But this wouldn't work well with JtR architecture. Or perhaps you could
store the comparison results in a bitmap and only transfer this ?
But even candidate password generation is a problem if you want to do it
on CPU. I toyed for a while with an alternate "markov" mode, where you
only generate the start of passwords on CPU and then you brute force
their end on the GPU.
> 4d) The final 5 additions / byte order reversals can be precomputed in
> reverse in host code and omitted in kernel code, that makes more sense if
> you have a single hash to crack. Actually the last 4 steps of the SHA1 can
> be partially reversed to speed it up a bit, but that depends on the design
> and I don't know if it's possible with JTR.
This can be done, and that is allowed by the design of the multiple
comparison functions.
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.
