[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 16 Feb 2012 13:41:10 -0600
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: Was: RE: [john-users] sha1 + hex salt
I think I will make another change to dynamic. This has been requested
before, I simply have not gotten to it.
I will add a new 'flag' to the format;
MGF_SALT_INP_HEX
What this will do, is cause dynamic to parse the given salt string as a
string of hex data (upcase/lowcase will not matter). Thus, the length must
be even. The final length of the salt will be 1/2 of the original string.
NULL data will be valid within the salts, etc.
Should not be that big of a change. This could be used to deprecate the
MGF_ColonNOTValid and the other 'stuff' out there to use a modified colon
character. If a format has binary salt values, which may contain colons,
the MGF_ColonNOTValid was a half baked way to work around that problem If
we have hex input for salts, then the problem can be eliminated, along with
having other 'hard' to represent data like \r\n\t \x0, etc being encoded
into the salt value. Those other 'hard' values, can make text file
maintenance, C string functions, etc, break, but if the input is in hex,
these problem can be fully worked around.
The other 'option' is to build this type flag: MGF_SALT_INP_ESC In this
mode, the salt would be a normal string, BUT it would be sent to the
demangle function of dynamic. In ESC mode, a \\ character outputs a \ and
a \xHH outputs the hex character listed. All other characters are emitted
without change. Thus, this allows encoding this string
A<LF>long<NULL>Salt:Value as the string A\x0Along\x00Salt\x3AValue
I really would not want to support both of these (flags are at a premium
within dynamic). Is there one format over the other which 'should' be
supported?
Jim.
>From: jfoug
>
>I have made changes to the dynamic format. The const values were 100%
>using
>memcpy type stuff, and a length value along with them. However, when
>loading
>a format, it used
>
>curdat.Consts[curdat.nConsts] = (unsigned
>char*)str_alloc_copy(Setup->pConstants[curdat.nConsts].Const);
>curdat.ConstsLen[curdat.nConsts] =
>strlen(Setup->pConstants[curdat.nConsts].Const);
>
>The str_alloc_copy, and the strlen, kind of blew the keeping of the
>length's, and using memcpy's, lol.
>
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.
