[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <af2b1bfafe156ea7ba73bb90de6e4bf1@smtp.hushmail.com>
Date: Wed, 23 Oct 2013 00:07:28 +0200
From: magnum <john.magnum@...hmail.com>
To: john-users@...ts.openwall.com
Subject: Re: bitcoin-opencl
On 2013-10-22 23:26, Solar Designer wrote:
> Just to clarify: you're aware that we already support this on CPU (in
> the bleeding-jumbo branch), and you want us to also support it on GPU
> (in OpenCL), right?
>
> Indeed, there's lots of room for optimization, and we do need to have
> the OpenCL-enabled format too.
https://github.com/magnumripper/JohnTheRipper/commit/89bf80fbd6df52ae7d04d94b3c3a826000b30549#commitcomment-4365911
The current CPU format may be somewhat flakey - it relies solely on a
padding check and it allows padding to be 4 bytes or more. IMO that is
too few bits to be used alone: We should get false positives. However
some empiric tests did not confirm that (I got no false positive in 180K
candidates):
Dhiru said he thinks the padding is always 16. I take it we are
ultimately not even sure it can't be shorter than 4 (false negatives
o.O). I'm not interested in doing that research but if someone else does
that, we can settle the CPU format and I'll be willing to write an
OpenCL format just to try AES on GPU.
magnum
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.
