[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <17e23bf5061accf3777d384d0fab54f4@smtp.hushmail.com>
Date: Thu, 30 Jan 2014 11:16:44 +0100
From: magnum <john.magnum@...hmail.com>
To: john-users@...ts.openwall.com
Subject: Re: Honey Encryption
On 2014-01-29 22:29, Solar Designer wrote:
> On Wed, Jan 29, 2014 at 09:55:02PM +0100, magnum wrote:
>> On 2014-01-29 20:47, Rich Rumble wrote:
>>> I haven't checked a recent version of John out, does AES256 zip still FP?
>>
>> Yes, and it's frequent enough the format is more or less unusable. It's
>> been moved to the broken/ subdirectory for now.
>
> I think that even a format producing very frequent false positives is
> somewhat usable - for finding very weak passwords and/or for
> pre-filtering a wordlist for testing by another cracker (e.g., a shell
> script invoking the target program). I think moving such formats to
> broken/ is wrong. Instead, maybe JtR should print a warning when the
> currently chosen format has FMT_NOT_EXACT set.
Actually the latter has been implemented since, so we can move them
back. The current warning message is:
Note: This format may emit false positives, so it will keep trying even
after finding a possible candidate.
But the real issue is that the format should be fixed. I think it's a
misuse of FMT_NOT_EXACT. That flag is intended for poor algorithms (eg
CRC32), not for poor implementations by us. Don't get me wrong, as long
as we do have a poor implementation the flag must obviously be set - but
it doesn't mean we're done with it. Just like a //FIXME comment in a
poor valid() doesn't. The list of such issues just grows so if we want a
good Jumbo release it won't happen anytime soon.
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.
