Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 30 Jan 2014 11:16:44 +0100
From: magnum <>
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.


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.