Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.