Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANO7a6xE6PexC9ruEqc7tx4Rj5R849t4seoWcQ=KFaeAOaDQSg@mail.gmail.com>
Date: Thu, 28 Jun 2012 10:25:44 +0530
From: Dhiru Kholia <dhiru.kholia@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Is saving 2 bytes per salt worth the effort?

On Thu, Jun 28, 2012 at 4:56 AM, Frank Dittrich
<frank_dittrich@...mail.com> wrote:
> diff --git a/src/episerver_fmt_plug.c b/src/episerver_fmt_plug.c
> index 4b46ffc..d89a0d7 100644
> --- 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!

> -       unsigned char esalt[18]; /* base64 decoding, 24 / 4 * 3 = 18 */
> +       unsigned char esalt[16];
>  } *cur_salt;
>
>  static void init(struct fmt_main *pFmt)
> @@ -104,12 +104,14 @@ static void *get_salt(char *ciphertext)
>        char *ctcopy = strdup(ciphertext);
>        char *keeptr = ctcopy;
>        char *p;
> +       unsigned char tmp_esalt[18]; /* base64 decoding, 24 / 4 * 3 = 18 */
>        static struct custom_salt cs;
>        ctcopy += 12;   /* skip over "$episerver$*" */
>        p = strtok(ctcopy, "*");
>        cs.version = atoi(p);
>        p = strtok(NULL, "*");
> -       base64_decode(p, strlen(p), (char*)cs.esalt);
> +       base64_decode(p, strlen(p), (char*) tmp_esalt);
> +       memcpy(cs.esalt, tmp_esalt, 16);
>        free(keeptr);
>        return (void *)&cs;
>  }
>
>
> esalt[18] is only needed temporarily, for base64 decoding.
> But the salt will always be 16 bytes.
>
> So, with an additional memcpy(cs.esalt, tmp_esalt, 16); we can get rid
> of two bytes per salt.
>
> Or should we rather use the last 2 bytes to store the version info after
> base64 decoding?
>
> (Or combine both ideas, use 17 bytes of esalt, and store the version
> info in the last byte?)
>
> For self test, this doesn't matter.
> But when processing a large number of hashes, saving 2 or even more
> bytes per salt might be a good idea.

How much does the extra memcpy call affect the benchmark?

-- 
Cheers,
Dhiru

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.