[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <57e7aab01a605c9a86e7e9344d890303@smtp.hushmail.com>
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.
