[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <EED030DB37FC434D995BBF3C77C9AD80@D9VGLK61>
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
