[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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.
