Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Thu, 12 Apr 2012 02:17:30 +0400
From: Solar Designer <>
Subject: MSCash2 formats reliability & usability

Jim, magnum, Lukas, Sayantan -

We have three JtR formats for MSCash2: CPU, CUDA, OpenCL.

The CPU one supports many different representations of MSCash2 hashes
and has many test vectors of different form ($DCC2$ prefix present vs.
not, iteration count included vs. not, username included vs. separate).
This is great, although the format's support for variable iteration
counts is probably unneeded (there are no non-10240 MSCash2 hashes in
the wild, as far as I'm aware).  However, I think with all this
complexity the format is also more prone to bugs than it has to be.
For example, with this combination of hashes in the input file:


John does not recognize the different salts (should be 3 different):

user@...l:~/john/magnum-jumbo/run$ ./john pw-bug -fo=mscash2
Loaded 7 password hashes with no different salts (M$ Cache Hash 2 (DCC2) [SSE2i 8x])

I guess there's a bug in prepare(), get_salt() or/and SALT_SIZE.  By
the way, it is weird how SALT_SIZE is defined as 11*4, but is actually
put into the struct as SALT_SIZE+4.  Assuming that this is the correct
value to use, we should specify SALT_SIZE as (11*4+4) right away.

Another issue is that strings of the above form are somehow also
recognized as "mscash".  I guess this has to do with
mscash1_fmt_plug.c's prepare() being too willing to turn anything into
what its valid() would recognize.  It should probably perform some
validation first.

Yet another issue is that strings of the form something#32hexdigits are
valid for "hmac-md5", so that's what the above ones are autodetected as.
Perhaps we want to have mscash and mscash2 (as well as their CUDA and
OpenCL varieties) checked before hmac-md5.  Maybe we should rename
hmacMD5_fmt_plug.c into non-plug and register it explicitly after other
stuff.  For consistency, maybe we should do it for hmacSHA1_fmt_plug.c
as well.  SHA-2 based HMACs are already non-plugins for another reason.

Finally, as it relates to the CUDA and OpenCL formats for mscash2, these
recognize only a subset of inputs that the CPU mscash2 format does.
Can we please bring the three in sync, including maybe by dropping
support for weird inputs (not actually used by anyone) in the CPU format?

BTW, the CUDA and OpenCL formats do not have the salts bug:

user@...l:~/john/magnum-jumbo/run$ ./john pw-bug -fo=mscash2-cuda
Loaded 7 password hashes with 3 different salts (mscash2-cuda [GPU])

user@...l:~/john/magnum-jumbo/run$ ./john pw-bug -fo=mscash2-opencl
OpenCL platform 0: NVIDIA CUDA, 1 device(s).
Using device 0: GeForce GTX 570
Loaded 7 password hashes with 3 different salts (MSCASH2-OPENCL [PBKDF2_HMAC_SHA1])

However, they fail to load this simple thing:

user@...l:~/john/magnum-jumbo/run$ cat pw
user@...l:~/john/magnum-jumbo/run$ ./john pw -fo=mscash2
Loaded 1 password hash (M$ Cache Hash 2 (DCC2) [SSE2i 8x])

user@...l:~/john/magnum-jumbo/run$ ./john pw -fo=mscash2-cuda
No password hashes loaded (see FAQ)
user@...l:~/john/magnum-jumbo/run$ ./john pw -fo=mscash2-opencl
No password hashes loaded (see FAQ)

Then, the CUDA and OpenCL formats currently have only one test vector.
They need to have many more.  I realize that this is a slow hash, yet
the self-tests currently test multiple key indices anyway, so I think
there would be no slowdown from having some more test vectors.

I think that most or all of the above needs to be corrected.



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.