john-users - RE: cracking RADIUS shared secrets with john the ripper

Openwall GNU/*/Linux 3.0 - a small security-enhanced Linux distro for servers

[<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.