|
Message-ID: <20151019165236.GA17249@openwall.com> Date: Mon, 19 Oct 2015 19:52:37 +0300 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Subject: Re: 64-bit rotate on AMD GCN On Fri, Oct 16, 2015 at 11:08:55AM +0300, Pavel Semjanov wrote: > #define sigma0_512(x) (ROR((x),1) ^ ROR((x),8) ^ ((x)>>7)) > T1 = X15=U64(0x220); > ... > s0 = sigma0_512(X15); > ... > > (Yes, it's SHA-512 ;) Maybe I've just managed to reproduce this. It turns out that our pbkdf2-hmac-sha512-opencl was failing on AMD GPUs (but working fine on NVIDIA). I didn't notice when playing with ror() before because I was focusing on sha512crypt-opencl (which worked fine on all of the GPUs). Changing this line in opencl_sha2.h: #define sigma0_64(x) ((ror64(x,1)) ^ (ror64(x,8)) ^ (x >> 7)) to: #define sigma0_64(x) ((ror64(x,1)) ^ (rotate(x,56UL)) ^ (x >> 7)) makes the problem go away for Tahiti (but the speed is poor, at about 1/4 of Titan X, unlike for sha512crypt where these GPUs are similar). Juniper is still failing (could be a different problem; I haven't looked into that). The fact that this matters for pbkdf2-hmac-sha512-opencl suggests that in that format we end up doing some computation on constants, which we could avoid by modifying the source code. Maybe this is also part of the reason why it's unexpectedly slow on Tahiti (in case not all of the computation on constants gets done at compile time). > I guess I had 15.7. I've just installed 15.7.1 and the bug still > exists. The GPU is R9 280x. And yes, it's Windows. > If you can't reproduce the bug, I'll send the full code. Anyway, I guess > it would be safer to define ROR8 separately. If the above was the same problem, then it looks like we can reproduce it with 15.7 on Linux as well. magnum - would you take this problem from here? 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.