[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <03fb01cd5fb3$74f60f80$5ee22e80$@net>
Date: Wed, 11 Jul 2012 17:21:01 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: request for new dynamic subformats
NOTE, sha256/224 ARE on my wish-list, as soon to be added, especially now that we have sha2 in JtR that does not depend upon oSSL version. The sha256/224 ‘should’ be able to be put into dynamic pretty easily, since they have a similar layout to sha1. Getting the 64 bit sha’s (sha384/512) into dynamic will likely be more difficult, since the internal data layout is different (64 bit, vs 32 bit), than any of the other crypts handled at this time by dynamic.
NOTE, the sha (1, 2) are handled in somewhat of a non-optimal way, in the dynamic format. This is due to dynamic being written originally to support LE based crypt (MD5). MD4 was trivial to add to dynamic, it has EXACTLY the same ‘layout’ as md5. But SHA is different. It is a binary BE format.
So, the way dynamic works for SHA, is if running in MMX code, the code to do the SHA, first translates all of the current input data into ‘flat’ values. It then loads these flat values up, into proper BE mmx input buffers, and runs the crypt. Once done, the code converts to base-16, into the proper MMX output buffers listed. The ‘FINAL’ SHA call, does not do a base-16 convert. It simply does BE to LE conversion into the normal output buffer1, then the format will compare those buffers, looking for cracked passwords. If JtR was built in a ‘flat’ model (i.e. not SSE buffering), then this conversion out of SSE to flat, and then convert back from flat into SSE does not happen.
This makes most usage of SHA about 10-15% slower in dynamic, than it would be, if done properly in a ‘FAT’ format. The SHA layout is not really the way I would like it to be, but working it into the existing dynamic format, does require certain amount of cooperation between the different types.
It may be good to make a SHA ‘targeted’ dynamic format, that allows MD5 (so 2 dynamic base formats). One that is targeted for SHA layout (or BE layout), would be work natively in BE formats, and then treat LE formats as the red-headed step child. They would work, but not be optimal. This may not be too bad of a thing, especially if the direction is going to be targeted towards SHA flavor of encryption, in the future. I think MD5 grew up for a while, and was very prevalent, but SHA-X may be starting to become the main target now.
Jim.
From: Elijah [W&P] [mailto:smarteam.support@...il.com]
What can be be popular now is sha256($salt.$pass) and extra points for the salt to be "regenable" (00-99)
http://forum.insidepro.com/viewtopic.php?p=99119#99119
This one is believed to be related with recent fоrmspring "incident"
Content of type "text/html" skipped
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.
