Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Sat, 31 Dec 2011 03:37:11 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: SSE/intrinsics for sapB/sapG [was: john-users]

On 12/30/2011 04:06 PM, magnum wrote:
> I added SSE/MMX/intrinsics to sapB, including with OMP. It's at least
> 2.5x faster now, near 10000K c/s on my old dual-core laptop.
>
> Will do sapG in the next few days.

It turns out sapG might not be that easy due to current limitations of 
sha1mmx() and SSESHA1body() of 64 + 55 bytes (right?). SapG's self-tests 
need between 58 and 100 bytes of data encrypted in the final crypt, but 
the theoretical max seem to be 248 bytes (48 bytes of plaintext + 40 
bytes of salt + maximum bad luck with the proprietry magic). I might 
give it a try anyway though, and just limit what salt (user name) length 
etc. that we accept.

Jim, Simon, how would I do a crypt of between 56 and 63 bytes? Is this 
not possible? Can we actually only do 0-55 *or* 64-119 bytes?

And how much would it take to introduce a way to do more 64-byte limbs, 
for 128+ bytes of data? Would that merely be another fairly trivial 
if/else in the intrinsics code, or is it more complicated?

magnum

Powered by blists - more mailing lists

Your e-mail address:

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