|
Message-ID: <013801cac84f$4d6fbae0$e84f30a0$@net> 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.