[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111231003927.CR5EM.183476.imail@eastrmwml206>
Date: Sat, 31 Dec 2011 0:39:27 -0500
From: <jfoug@....net>
To: john-dev@...ts.openwall.com
Cc: magnum <john.magnum@...hmail.com>
Subject: Re: SSE/intrinsics for sapB/sapG [was: john-users]
> Cool, I'll try it out. But I still don't get how the functions can tell
> the difference between an ending 0x80 and one that is *part* of data
> (perhaps coincidentally followed by lots of nulls plus something that
> could be a length word, but all being just parts of a 64-byte binary
> data block)
Here are a few examples:
to sha 0 bytes build this buffer:
64 bytes. the first byte is 0x80. ALL other bytes are zero's, since we padd any bytes to the right of the 0x80 to null, and then set the number of bits, to 0 (last 8 bytes).
To sha the letter 'a', build this buffer:
64 bytes. First byte is 'a'. 2nd byte is 0x80. Null all other bytes. Set the uint64 (last 8 bytes), to 8 (number of bits).
To sha 60 letter 'a's, build this buffer:
128 bytes. First 60 bytes are 'a'. Then 0x80. Then null all bytes up to 120. The last 8 bytes are 60<<3 (480 bits).
Now for 'our' code, the first 2 are the normal 1 64 byte limb encryption. The last one (the 60 letter a's), requires 2 calls to the SHA code, to encode the 2 blocks. The first requires normal init, the 2nd call requires getting it's init from the results of the first block encryption.
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).
NOTE, if most of our data WAS long strings like this, it may be faster, to build a function that does the crypt 'init', then build a function JUST for the body (the part where we loop over each 64 byte buffer), then build a function to do the post crypt code (to get the results). Then, we do not store the results after each 64 byte block, and reload the init before the start of the next block. However, doing this, we would either have to allocate our own private key block, or lose thread safety. Right now, the key is on the stack (in the SSE2i code), and we either initialize it with default values, OR with results from prior crypt.
We 'might' want to take this off list, if you still have any questions left.
Jim.
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.
