Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 10 Jul 2013 12:04:28 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: PBKDF2 hash_out treatment

On 10 Jul, 2013, at 9:24 , marcus.desto <marcus.desto@...pl> wrote:
> Check the crypt_all() call inside opencl_mscash2_fmt.c . The function pbkdf2*() inside cryprt all takes dcc hash as input and produce dcc2 aka mscash2 hash as final output. These output hashes are compared against given test hashes or the loaded hashes during a cracking session. 
>  
> Regards,
> Sayantan  
> 
> 
> I understand. I also read another *fmt.c files, which seem to contain running and testing parameters for pbkdf2 function, too.
> Well, I recodnized that the output buffer always is a struct of specific size containing an array of unsigned int (as declared in parameters of the derive_key oder directly the inline function pbkdf2 in file pbkdf2_hmac_sha1_unsplit_kernel.cl ). I also read that it depends on the type of purpose, how you use or compare it, for example using 3DES in opencl-krb5pa-sha1_fmt.c . But I do not really understand, how to extract the sha-1 hash from that uint buffer for generic purposes.
>  
> I tried a cpu pbkdf2-hmac-sha1 implementation that returns another hash directly as a string as expected, but from the open implementation I get a uint32 array that does not contain the expected hash values, even when I try to extract them by transforming each array cell into hex and seperating those hex cell values by byte in little endian byte order - EVEN all the parameters for the pbkdf2 function call are the same running ONLY 1 iteration

What are you ultimately trying to achieve? In general it's not a good idea to use JtR to produce complete, standard-formatted hashes because much of that is often optimized away. For example, since SHA-1 is big endian, chances are you will not see the little endian you are looking for (instead, we byte swap the target hash(es) - this saves us from gazillions of swapping operations). And the CPU formats would normally use SIMD on x86, so the output might be interleaved or coalesced.

Also, I'm not sure but I would assume the mscash2-opencl format does not support an iteration count of 1, again because of optimizations.

magnum

Powered by blists - more mailing lists

Your e-mail address:

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