Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 16 Feb 2012 15:54:52 -0600
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: Was:  RE: [john-users] sha1 + hex salt

The 'hex' would often be used to modify some 'native' format, simply to jam
it into the limitations of john (the text file format, and the C language
string functions).  The ESC string format, was simply something I 'added'.
It allows most of the strings to be native, but gives you the ability to
escape certain non-working characters,  ':'  \n  \r, NUL, (possibly anything
outside of <space>-<~>, i.e. control or 8 bit.).  Hex does that also, but it
forces everything to be escaped.

You see hex input in the phps format, and a few others (which were put into
dynamic).  Part of the convert() function within the these 'thin' formats,
is the undoing of the hex.   

<!light!>

I had totally forgotten about $HEX$

I have to dig back through the dox and code, and try to remember just what
we did with this flag within the strings.  This may be what is needed, and
an extra flag is something extraneous, and not required.

Jim.

>From: magnum
>
>My vote would be for hex. I have never seen the \xnn format in any
>native hashes. I would guess a native escaped salt would more likely be
>using URL type escaping - like %3A for the colon. But hex would be the
>better start anyway.
>
>magnum

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ