[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <4EFE7557.8060208@hushmail.com>
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
