Date: Tue, 6 Dec 2011 10:32:24 -0600 From: "jfoug" <jfoug@....net> To: <john-users@...ts.openwall.com> Subject: RE: cracking RADIUS shared secrets with john the ripper >You have to have multple lines (i.e. multiple salts), before this makes >any difference. If john runs a salted format, and there is only one >salt, it switches into a 'non-salted' method of attack. But if you run >this file: > >crack:$dynamic_1008$af25d95ad759e0f43921be2782d10b74$HEX$7ae3c680caee7171e2 8e0409b2e2f3ab >crack:$dynamic_1008$bf25d95ad759e0f43921be2782d10b74$HEX$7ae3c680caee7171e2 8e0409b2e2f3bb >.... I did some testing, with a the fake hash data I had provided before, and the same fake data, but with the HEX$ and first 16 bytes of the salt removed. I ran the HEX$ version with a dynamic with the set_salt code added, and ran the 16 byte trimmed down salt against a john build without that set_salt change. The results were than the changes in set_salt to do the HEX conversion only slowed this format down about 2% to 3%. Not a significant change, so I would say your modifications for v1.7.8 are more than adequate in performance. I am going to look at making some core changes to the salt building, to try to get a 2 to 3% 'gain' against current version (simple salted performance). These changes WILL contain the new HEX$ processing. However, there will be no memory copying within the set_salt, it will be done with pointer assignment only. This should avoid double buffering the data, like is being done today. Today, we double buffer. For the 1.7.8-$HEX$ salts, we triple buffer. 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.