Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 6 Dec 2011 10:32:24 -0600
From: "jfoug" <>
To: <>
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:

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

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

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.


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.