Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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.