[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 20 Mar 2010 12:03:45 -0500
From: "Jim" <jfoug@....net>
To: <john-users@...ts.openwall.com>
Subject: RE: salted triple-SHA1
-----Original Message-----
>> sha1($salt.sha1($salt.sha1($pass)))
>I think the simplest way would be to define a new "format" that would
>use OpenSSL's SHA-1 routines like some others do.
>> I was thinking of the new generic MD5 mode, modified to SHA1 (such
>> as: username:sha1_gen(1)e6240f5404d2c1004aed37a66550a5b1ea60c469
>> $b295d117135a9763da282e7dae73a5ca7d3e5b11), but I'm afraid that's
>> beyond my coding skills.
>>
>> I'd give it a go though, if someone could give me a raw sketch of the
>> steps involved.
>I think this approach would be significantly more complicated than
>defining a special-purpose "format" like I proposed above. I wouldn't
>mind "a raw sketch of the steps involved" appearing in here, on the
>wiki, or in a documentation file, though. Jim?
This is actually on my todo list (same or similar as the generic md5).
But a lot has been put on hold, since I have been so busy at work, since
the wife has been sick over the last year, and then most recently, since
I do not have a decent development machine at home right now. several
'want to do' things, but simply not the drive to get it done.
The 'deeper' I got into the md5 stuff, the less 'generic' the end code
ended up being. It still 'is generic, but there were many special
optimization functions added, mostly for loading or checking, that
a true generic was not the end result.
For 'simple' things such as the hash listed above
sha1($salt.sha1($salt.sha1($pass))), as long as the intermediate data
is done in a common way (such as base-16 lower case strings), then building
a sha 'generic' set of functions, using nothing more than openSSL code,
would not be that hard to do. This would be decent code if we were doing
MD5 (but assuming SHA1 was 'done' also). Note, if salt was a 'fixed' size
We may be able to do other optimizations also. But this format can
certainly
be 'tuned' to take only 2 SHA1 per salt/password computations, if there are
enough candidate hashes to try.
gen_sha1(1001)
Flag=MGF_SALTED
Flag=MGF_NOTSSE2Safe (Not sure on this one, likely depends on length of
salt)
Flag=MGF_KEYS_CRYPT_IN2 (fills in out2[] with sha1($pass) )
Func=SHA1GenBaseFunc__clean_input
Func=SHA1GenBaseFunc__append_salt
Func=SHA1GenBaseFunc__append_from_last_output2_to_input1_as_base16
Func=SHA1GenBaseFunc__crypt
Func=SHA1GenBaseFunc__clean_input
Func=SHA1GenBaseFunc__append_salt
Func=SHA1GenBaseFunc__append_from_last_output_as_base16
Func=SHA1GenBaseFunc__crypt
I have code for the MD5 which goes beyond what is in current jumbo patch.
The problem is, that I also have all sorts of debugging and timing code
scattered throughout it, and it is not release ready. The code really
needs to be properly done, and done so that SSE2 intrinsic code works
properly and fast on 64 bit machines. I had started down that path
many months ago, but have lost a lot of my time, and now my machine.
Thus unfortunately, it has been put on hold. The code in the jumbo
patch is pretty solid, and contains the tools to do a lot. I simply
have not had time to complete it (it will likely never be totally
'complete' and then I was going to start on SHA1. It is still a
project I would like to get to this spring, but I can not make any
assurance of that.
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.
