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.