[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 28 Jun 2012 14:18:33 +0200
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Is saving 2 bytes per salt worth the effort?
On 06/28/2012 02:02 PM, jfoug wrote:
>> From: Frank Dittrich [mailto:frank_dittrich@...mail.com]
>>>> --- a/src/episerver_fmt_plug.c
>>>> +++ b/src/episerver_fmt_plug.c
>>>> @@ -76,7 +76,7 @@ static ARCH_WORD_32 (*crypt_out)[BINARY_SIZE /
>>>> sizeof(ARCH_WORD_32)];
>>>>
>>>> static struct custom_salt {
>>>> int version;
>>>
>>> "int version" can be changes to "char version". Even more savings!
>>
>> That was my second idea:
>
> Changing int to char will save no space, on most compilers. This is in a
> structure, and most will align all structure members on a natural word
> boundary (int).
You actually snipped the quoting with my idea:
>> Or should we rather use the last 2 bytes to store the version info after
>> base64 decoding?
So, currently we have:
static struct custom_salt {
int version;
unsigned char esalt[18]; /* base64 decoding, 24 / 4 * 3 = 18 */
}
The last 2 bytes of esalt used just temporarily for base64 decoding,
so I can use them for a 2 byte version information, leaving just an
unsigned char esalt[18] instead of a structure.
Even if this gets aligned or you enforce alignment, it should be just 20
bytes.
> Just an FYI when thinking about pinhole tweaks like this. Many
> 'optimizations' like this will gain absolutely nothing, and can cause other
> problems.
If loading large amounts of hashes, the difference could be whether all
the data fits into a cache (or into RAM)...
Of course, there are other problems to be taken care of, and most
probably for this format there are still some other optimizations
possible which gain more than just saving 2 bytes...
Frank
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.
