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