Date: Thu, 12 Apr 2012 02:17:30 +0400 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com 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: $DCC2$Joe#e09b38f84ab0be586b730baf61781e30 $DCC2$test#a86012faf7d88d1fc037a69764a92cac $DCC2$administrator#a150f71752b5d605ef0b2a1e98945611 $DCC2$administrator#c14eb8279e4233ec14e9d393637b65e2 $DCC2$administrator#8ce9c0279b4e6f226f52d559f9c2c5f3 $DCC2$administrator#2fc788d09fad7e26a92d12356fa44bdf $DCC2$administrator#6aa19842ffea11f0f0c89f8ca8d245bd 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 test:a86012faf7d88d1fc037a69764a92cac 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. Thanks, Alexander
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.