[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CANJ2NMNvHHjMOub3-DEwAPiqaqoY6B_unyi07HN3afQyH9_Xow@mail.gmail.com>
Date: Fri, 29 Jun 2012 21:23:01 +0800
From: myrice <qqlddg@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: raw SHA-512 and XSHA512 CUDA/OpenCL (was: Jumbo-6
release status)
On Fri, Jun 29, 2012 at 7:36 PM, Solar Designer <solar@...nwall.com> wrote:
>
> OK. I am glad that this was easy to fix. Now your task is to figure
> out why BINARY_SIZE of 8 did not work - or rather, why it worked for
> the self-tests, but not the rest. And to reduce BINARY_SIZE back to 8
> once you figure this out and fix whatever did not support that lower
> size. This ought to work with 8 (with suitable code).
>
In loader.c, we allocate format->param.binary_size for each binary. If
we have a binary size less that the actual size(64), we will only have
first 8 bytes binary and discard the remains.
In self_test, this is different. We don't allocate memory for binary.
We only point to the test array. So we will get the full binary.
And why 8 bytes binary doesn't work. I have reduced sha512 round from
80 to 77. The 3rd 8 bytes will be uses for comparison. We lost these
bytes if the BINARY_SIZE is set to 8. What's more, with 8 bytes
binary, the cmp_exact() should not work either.
So reduce the BINARY_SIZE to 8 is not necessary. It supports lower
size. The reason is we lost some binary bytes..
Thanks
myrice
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.
