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.