|
Message-ID: <BLU0-SMTP1168E79BB592D19C215DE89FDE70@phx.gbl> Date: Thu, 28 Jun 2012 01:26:58 +0200 From: Frank Dittrich <frank_dittrich@...mail.com> To: john-dev@...ts.openwall.com Subject: Is saving 2 bytes per salt worth the effort? 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; - 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. 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.