Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 23 May 2015 16:22:33 +0300
From: Aleksey Cherepanov <lyosha@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: interleaving in SHA256 & SHA512

On Sat, May 23, 2015 at 02:27:47PM +0300, Aleksey Cherepanov wrote:
> On Sat, May 23, 2015 at 10:55:38AM +0800, Lei Zhang wrote:
> > I managed to add interleaving to SHA256 & SHA512, but the work is incomplete yet. When the interleaving factor is set other than 1, SHA256 works with a few formats, and SHA512 only works with sapH currently. Below are some statistics obtained from experimenting various interleaving factors:
> 
> I am trying interleave in john-devkit on raw-sha512 with sse.

> I may try to not unroll main cycle and use
> higher interleave factor. So there may be a follow-up mail.

No unrolls at all (gcc may unroll something on its own):

x1
Raw:	1898K c/s real, 1898K c/s virtual
608 asm
2761 bytes of code

x2
Raw:	1886K c/s real, 1886K c/s virtual
946 asm
4372 bytes of code

x3
Raw:	1611K c/s real, 1627K c/s virtual
1100 asm
5014 bytes of code

x10
Raw:	1423K c/s real, 1423K c/s virtual
3243 asm
14991 bytes of code

xN is interleave factor. Data is grouped by "words":

static $type saved_key[(PLAINTEXT_LENGTH + 1 + 16) / $size][$interleave][$vsize];

So all 1 words from all candidates are first, then similarly for 2
word and so on. It turned out to be a bit faster than grouping by
blocks: full candidates #1 and #2, then full candidates #3 and #4...

I am concerned that size of code does not follow interleave factor 1
to 1, but it may be due to unrolls by gcc.

-- 
Regards,
Aleksey Cherepanov

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ