|
Message-ID: <e71dd655d5ce6e6705ff46c1cf68c47d@smtp.hushmail.com> 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.