Date: Sun, 16 Dec 2012 23:15:13 +0100 From: magnum <john.magnum@...hmail.com> To: john-users@...ts.openwall.com Subject: Re: gpg2john -> false positive -> how to exclude? On 16 Dec, 2012, at 21:04 , john@...jenski.de wrote: > is it possible to let john go on with brute-forcing in incremental mode, after > an obvious false positive is found? Some formats are expected to have collisions, like CRC32 for instance. You can make any format behave like such by adding FMT_NOT_EXACT to the format flags in the end (normally) of the source file. In this case, this line: FMT_CASE | FMT_8_BIT | FMT_OMP, of gpg_fmt_plug.c (or opencl_gpg_fmt.c) would be FMT_CASE | FMT_8_BIT | FMT_OMP | FMT_NOT_EXACT, However, see below. > I recently did 'gpg2john' and finally ended up with incremental mode and got an false positive. > I forgot my gpg-passphrase (from >10 years ago), and I know it's not the found word, besides: > it simply does not work :) As far as I understand from the source, it should really not emit false positives. Maybe there is a bug in the format. At worst that means once Dhiru fixes it you'd have to re-start from scratch. We might need more information. Were you running the CPU format or the OpenCL one? And are you using Jumbo-7 or the unstable-jumbo from git? Would you by any chance reveal the gpg key or input file (perhaps privately, to Dhiru) so we can reproduce the bug? I take it you do not use that passphrase anymore anyway :) Failing that, I guess we'd be helped by knowing what exact time key it is. magnum
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.