[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
