gpg-opencl "WaitForEvents failed" for 8:SHA256 9:AES256

openwall / john

John the Ripper jumbo - advanced offline password cracker, which supports hundreds of hash and cipher types, and runs on many operating systems, CPUs, GPUs, and even some FPGAs

https://www.openwall.com/john/

Other

10.06k stars 2.08k forks source link

gpg-opencl "WaitForEvents failed" for 8:SHA256 9:AES256 #2784

Closed solardiz closed 7 years ago

solardiz commented 7 years ago

Loaded 1 password hash (gpg-opencl, OpenPGP / GnuPG Secret Key [SHA1 OpenCL])
Cost 1 (s2k-count) is 65536 for all loaded hashes
Cost 2 (hash algorithm [1:MD5 2:SHA1 3:RIPEMD160 8:SHA256 9:SHA384 10:SHA512 11:SHA224]) is 8 for all loaded hashes
Cost 3 (cipher algorithm [1:IDEA 2:3DES 3:CAST5 4:Blowfish 7:AES128 8:AES192 9:AES256]) is 9 for all loaded hashes
Warning: OpenMP is disabled; a non-OpenMP build may be faster
OpenCL CL_INVALID_EVENT (-58) error in common-opencl.c:1515 - WaitForEvents failed

The same happens on other devices.

I didn't investigate which exact property of the key causes this failure, but I guess that maybe we just don't have this hash and/or (more likely) this cipher implemented in the OpenCL format? If so, we should either implement what's missing or properly report the error.

--format=gpg appears to run against the same input fine.

magnumripper commented 7 years ago

maybe we just don't have this hash and/or (more likely) this cipher implemented in the OpenCL format? If so, we should either implement what's missing or properly report the error.

If at all possible, we should reject it in valid.

solardiz commented 7 years ago

Rejecting in valid() is only a good idea if we also print a message explaining why. Otherwise it'd be very confusing: gpg2john produces output that john would not recognize as valid.

magnumripper commented 7 years ago

We can/should print a warning but we must reject hashes we do not support (if possible). That's more important than anything else. Otherwise we'll have false negatives.

Otherwise it'd be very confusing: gpg2john produces output that john would not recognize as valid.

John would recognize it as valid with the CPU format. We have several such cases already.

solardiz commented 7 years ago

BTW, the CPU format already lists more ciphers:

Cost 3 (cipher algorithm [1:IDEA 2:3DES 3:CAST5 4:Blowfish 7:AES128 8:AES192 9:AES256 10:Twofish 11:Camellia128 12:Camellia192 13:Camellia256]) is 9 for all loaded hashes

So maybe 9:AES256 is supported in our OpenCL format, and the failure is then because of something else.

kholia commented 7 years ago

The gpg-opencl format automatically uses the CPU code for hashes it can't handle on the GPU. Jim added this functionality.

This means that the gpg-opencl format will support all the hashes generated by gpg2john. Isn't this the case?

@solardiz Isn't CMIYC contest over now? If yes, please post the problematic file / hashes.

magnumripper commented 7 years ago

The gpg-opencl format automatically uses the CPU code for hashes it can't handle on the GPU. Jim added this functionality.

If it's 100% CPU, we should revert that IMO. Having it different from all others is just confusing and will lead users to think JtR is slow as hell.

solardiz commented 7 years ago

Also, why does it list fewer options for "cost 3", then? A bug? Anyway, that would be a separate bug from what I am reporting here. (So let's not forget that separate bug as well.)

This is unrelated to CMIYC. Google 0x33E9E596.

solardiz commented 7 years ago

I think using the CPU for ciphers is fine (most time is still spent in OpenCL kernels, on the hashes), but for hashes is not for the reason magnum mentions.

kholia commented 7 years ago

@solardiz previously reported sporadic self-test failures with our gpg-opencl format. I was able to reproduce the problem but I could not solve it. By limiting the test-vectors to values really supported on the GPU, the reliability of the gpg-opencl format improved (did it become 100% stable?).

Overall, I am OK with removing this hybrid CPU + GPU functionality from the gpg-opencl format. I think I will be able to tweak the valid function in gpp-opencl to be more informative.

Update: See https://github.com/magnumripper/JohnTheRipper/issues/2242 (it discusses reliability problems with gpg-opencl).

kholia commented 7 years ago

@solardiz Thanks! I have 0x33E9E596 keypair downloaded now for testing.

kholia commented 7 years ago

If it's 100% CPU, we should revert that IMO. Having it different from all others is just confusing and will lead users to think JtR is slow as hell.

Jim already considered this case.

commit 48b55aed6bca648173649d9d7631d6361e5459c0
Author: jfoug <jfoug@cox.net>

    gpg-opencl: issue warning when running and there are hashes which would use CPU code

Update: It also seems that gpg-opencl used to print a warning for unsupported hashes saying [-] gpg-opencl currently only supports keys using iterated salted SHA1.