Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 03 Aug 2015 04:39:38 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: JtR on ARM (NEON)

On 2015-07-31 10:35, Solar Designer wrote:
> On Fri, Jul 31, 2015 at 03:58:27PM +0800, Lei Zhang wrote:
>> Benchmarking: sha512crypt, crypt(3) $6$ (rounds=5000) [SHA512 64/32
>> OpenSSL]... DONE
>
> BTW, the 64/32 here is wrong.  Should be 32/32.  Just because an
> algorithm uses 64-bit integers logically doesn't mean we should
> report it as using 64 out of 32 physical bits, since it can't.
> magnum?

It looks like Jim lost a few lines when adding SIMD support. Fixed now.

>> From the figures above, MD4 and MD5 get 2x speedup; SHA1 and SHA256
>> have no speedup; SHA512 gets a lot slower.
>
> Yes.  That's weird(...) Maybe unaligned accesses.

How slow is NEON with unaligned scalar 32-bit? The raw formats' 
set_key() read the key (which may be unaligned) using 32-bit loads and 
places directly in the SIMD buffer. It might be a coincidence that 
MD4/MD5 happens to get aligned test vector keys and the others doesn't. 
Other than that I can't see what would be unaligned.

magnum

Powered by blists - more mailing lists

Your e-mail address:

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