|
Message-ID: <20130418203934.GA28870@openwall.com> Date: Fri, 19 Apr 2013 00:39:34 +0400 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Subject: Re: [patch] sse/xop implementation of raw-sha512 On Thu, Apr 18, 2013 at 10:33:32PM +0200, magnum wrote: > @@ -293,11 +300,11 @@ static void set_key (char *key, int index) > uint8_t *buf8 = (uint8_t * ) buf64; > int len = 0; > > - while (*key) > + while (*key && len < MAXLEN) > buf8[len++] = *key++; > > > In Jumbo, we are already guaranteed that keys passed to set_key() fits max length. Yes, I recall you and JimF discuss that. > OTOH in this case I get no gain right now from removing this check. For me, adding this "len < MAXLEN" sped things up from 10M to 11M c/s on FX-8120/OpenMP. I guess the knowledge that "len <= MAXLEN" upon exiting this loop let the compiler optimize the rest of the function better, or something like that. > buf64[15] = len << 3; > buf8[len++] = 0x80; > - while (buf8[len] && len <= MAXLEN) > + while (buf8[len] && len < MAXLEN) > buf8[len++] = 0; > > > I believe this is wrong. We get a 0x80 in buf8[MAXLEN] after a max-size key. Yes. Our messages crossed. > Too bad the max-length self-test did not catch this. What it did was reliably prevent further passwords from being cracked, except for max-length ones. Thanks, Alexander
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.