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

On 12/31/2011 06:51 AM, jfoug@....net wrote:
>
>> To do 300 letter a's, it would be the same.  We build the buffer to be 320 bytes long.  300 letter a's, followed by a bit (0x80), followed by null byte padding, followed by an 8 byte long int of number of bits (320*8).
>
> Correction:,   that would be 300*8 as the number of bits.

Thanks, I think I start to get it. Maybe we could add a couple of API 
calls for doing some things with more ease.

If we had a format that always needed n buffers we could have a GETPOS 
that actually spans n key buffers, and a crypt call (or macro) that do 
all of them. Then I think the fmt.c would not need to handle anything 
specially.

But I guess the real problem is if *some* of the keys are shorter than 
56 bytes and some of them are longer. I suppose I'd have to do it this way:

1. set up key buffers
2. crypt
3. store the crypt_out for keys that were <56 bytes
4. set up key buffers with the second half of longer keys
5. crypt
6. merge this output with the one stored in #3 to get the correct final 
output for both lengths

Right? Or is there a way to make the second crypt not trash the output 
that was final already?

Otherwise, I suppose I could try to collect separate batches, one with a 
1x buffer for <56 keys and another with a 2x buffer for >=56 keys (maybe 
even a third 3x one), and crypt when either of them are full. This will 
be tricky to optimise. Who needs Sudoku? :)

I presume crypting 56 bytes (using two calls) will take about twice as 
long as crypting 55 bytes? Maybe this is the case for the non-vector 
code too.

magnum

Powered by blists - more mailing lists

Your e-mail address:

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