[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 16 Feb 2012 22:33:07 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Was: RE: [john-users] sha1 + hex salt
On 02/16/2012 08:41 PM, jfoug wrote:
> 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.
...
> 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?
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
