Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 16 Mar 2011 00:24:19 -0500
From: "JimF" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: Re: Speedup of x86 .S build of raw-sha1 format

>From: "Solar Designer" <solar@...nwall.com>
> To "make sure" it is sufficient to clean the smaller portion of
> saved_key only, you could want to fill the rest of it with some
> non-zero value, like:
>
> memset(saved_key, 0x55, sizeof(saved_key));
> memset(saved_key, 0, 64*MMX_COEF);

This is the code I did:

memset(&saved_key[64*MMX_COEF], 0x55, sizeof(saved_key)-64*MMX_COEF);
memset(saved_key, 0, 56*MMX_COEF);

Also, changed the PLAINTEXT_SIZE to 55, and it finds PW's up to 55 bytes 
just fine.

Actually, it looks like only  memset(saved_key, 0, 56*MMX_COEF); is 
required.   I think the 2 upper int32's in the saved_key[16] never get 
overwritten, either.  In the init, the whole sizeof(saved_key) is memset. 
Then ints saved_key[14] and saved_key[15] only get 4 bytes written to (the 
length to a single byte, since it is always < 55

Thus it appears to 'clear' the .S version of the SHA1 SSE/MMX buffer, you 
need to only clean the first 14*MMX_COEF ints.

To test, I ran against a set of SHA1's which had 45 to 58 byte hash values. 
Every one of them from 45 to 55 were found.  I have mixed up the input (and 
rerun several times), and mixed up the dictionary file, and rerun (several 
times).  Each time, john found all data, so I think these changes allow it 
to work just fine.

NOTE, if as was in the code originally (PLAINTEXT_LEN 32), you would only 
have to memset (36*MMX_COEF)   32 for the possible text, and the next array 
of int's for passwords 32 bytes long, where the 0x80 would fall into the 
next int.  But I bumped up PLAINTEXT_LENGTH to 55, to find longer passwords. 
If 32 is long enough, then the memset can be reduced even more.

This change does appear to be safe.  The first 64*MMX_COEF only get written 
to in the key load.  They are not touched by the SSE code, except the very 
last 2, which always get the same bytes written to with the length.  The 
'extra' is just a rolling feedback buffer.  Any data will first be written, 
prior to being read.  Thus the memset is a waste.

Jim. 

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ