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 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

Your e-mail address:

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