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