[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <05EE827AC97045099ED0EC3591D1FE4F@ath64dual>
Date: Thu, 9 Jul 2009 19:48:29 -0500
From: "JimF" <jfoug@....net>
To: <john-users@...ts.openwall.com>
Subject: Re: patch for new john format: phpass (also works for phpBBv3)
>> This version adds salt hash, binary hashes and sets the copyright data to
>> be what was recommended.
>
> Great.
the hash_salt was really needed for loader functions. The binary_hash
stuff was probably not needed as much, due to this format having
such a good salt value.
I am still taking baby steps in the code. I am working out just what
parts need to be set for each 'type' of format.
> I see that you're doing some weird
> stuff with strchr() calls on itoa64. I recommend that you use
> atoi64[ARCH_INDEX(...)] instead,
Done. Again, I am still learning, and just getting my feet wet. But the
change to atoi64[ARCH_INDEX(...)] does make the code much cleaner.
The one issue I had is:
static void phpassmd5_set_salt(void*), so using ARCH_INDEX()
I get this problem (in VC at least), claiming:
'Error C2036: 'void *' : unknown size
so, here I had to typecast to char* within the ARCH_INDEX macro. Of
course, I use a char* in the parameter of the function (C lets me write
code with different parameters), but I would rather have the param be
proper, and typecast internal.
> Also, in phpassmd5_binary() you convert pointers, which may be
> 64-bit, to (unsigned), which is usually 32-bit. Chances are that this
> will work right anyway, because you only use pointer differences in the
> end (so dropping the high 32 bits shouldn't affect the results), yet
> this is wrong. Switching to the use of atoi64[ARCH_INDEX(...)] will
> eliminate the need for the pointer math anyway.
Actually, that conversion is simply taking a 16 byte array of binary
stuff. It then typecasts to 32 bit array, dereferences first element
and strip's of the lowest X bits. The exact same method is used within
the phpassmd5_get_hash_X functions, against the just encrypted data.
The typecasts should line up, and match just fine, in either a 64bit
or 32 bit system. All this is doing is grabbing the highest 8 bits
(for the get_hash_0 and get_binary_0) from the 16 byte hash, or it
gets the the 4th byte if the system is BIG_ENDIAN. However, both
get_hash_x() and get_binary_x() do the same way, so even though a
different byte of the buffer is returned for LITTLE vs BIG endian,
it will still function properly. Now, if there are performance gains
to be had on 64 bit systems for staying away from 32 bit access, then
I could change the typecasts to (unsigned) so that the 64 bit op-codes
are used. However, I doubt that would make any difference at all,
since the 2048 MD5 hash calls for EACH password, far outweigh any
optimizations in this part of the code, :)
> P.S. Please don't over-quote when you post to the list.
10-4. Sorry.
I now have a phpass-3.diff (but I need to test some). But as we talked
about before (off list), I will look at getting this out in the bigger
set of changes I have. I will post that message shortly, to the list
as you wanted.
Jim.
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.
