[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 9 Dec 2011 12:52:02 -0600
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: cracking RADIUS shared secrets with john the ripper
>From: Didier Arenzana [mailto:darenzana@...il.com]
>
>On Fri, Dec 9, 2011 at 5:23 PM, jfoug <jfoug@....net> wrote:
>> Hopefully, I will have this fully tested and released today.
>
>Thank you! I guess I will just wait until it's released... I was still
>scratching my head thinking how to achieve the modifications you
>suggested with the salt structure :)
It has been posted as patch 0043- the salt() function now does all of the
work, including figuring out what salts are identical. Dynamic returns 4
byte or 8 byte 'salts' back to john, which will always be unique. These 4
or 8 bytes are simply the data contents of a pointer.
I have also added code within valid, to 'undo' the HEX$ strings, so that
salt length safety-detection code works properly, and also so that we do not
discard candidates which really do 'fit' into the specifics.
>I will stick on my rad2john perl script then; and have a related
>question: what is the absolute maximum length for a salt in dynamic_n
>format ? The attack on radius responses use a whole packet as salt, so
>it can get pretty big, I want to check in the script if it does not
>generate too big salts.
This depends upon how you have written the format. If you write them
non-SSE, then any length salt 'should' work. With the changes I have made,
I can easily do this. Prior code would have been hard, because we had to
return max_length often, if we did not know, since many formats do not
specify the max salt length. There is still 'some' of that logic within
john. I think the max length at this moment (fully updated 1.7.9 up to
patch 0043), I think is somewhere in this area: #define SALT_SIZE
(64*4+1+3+1) NOTE, I have not validated this. The format would HAVE to
be written to handle this. Keep in mind, that for x86 mode (i.e. anything
other than MMX type builds), the buffers where you manipulate input data
(and do the crypts from), is only 124 + 96 bytes, and I believe that on
'some' builds, those extra 96 bytes are used by the crypt code, as temp
storage. So it may be that the largest salt you can 'use' is password_len -
124.
NOTE, for any MMX build, unless you switch the data into and out of x86 type
buffers, the max salt you can use is 55-password_len bytes long. This
limitation is where most of the 'bullet proofing' of lengths within the
built in types in the dynamic format come from.
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.
