[<prev] [next>] [thread-next>] [day] [month] [year] [list]
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.
