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
Powered by Openwall GNU/*/Linux - Powered by OpenVZ