Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 17 Apr 2015 04:36:37 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Advice on proposal: John the Ripper jumbo robustness

Hi Kai,

On Fri, Apr 17, 2015 at 09:21:03AM +0800, Kai Zhao wrote:
> Maybe I was wrong.

Yes, you were.

> There are 2 reasons:
> 
> 1. I want to bypass this function, since the AFL documentation declares that
> "As with any other brute-force tool, the fuzzer offers limited coverage if
> encryption, checksums, cryptographic signatures, or compression are used
> to wholly wrap the actual data format to be tested.".
> 
> 2. This function occupies most of time. I want to make it start faster, so I
> comment this function.

When we asked you to profile JtR to speedup its startup for quicker
fuzzing, we never meant profiling actual cracking.  (And you let it run
for what, like an hour?  That's ridiculous.  It'd make sense for
subsequent optimization, but not for subsequent fuzzing of the startup
code.  You were meant to profile a sub-second invocation of "john", and
make it even more lightweight.)

The function in question is part of the actual cracking.  Even if you
comment it out, but let the actual cracking code be reached, JtR would
continue running there... well, unless you make it "crack" all of the
hashes quickly - but this doesn't take any patching to do.

Your first task is to fuzz primarily the startup code.  That's where
almost all parsing of JtR's input takes place.  Thus, you should prevent
the start of cracking.  This is easily accomplished by providing input
files that are not actually valid() hashes.

At a later time, you may in fact fuzz post-valid() parts of JtR as well.
To do that, you may use a combination of hashes and cracking mode and
its settings that will result in all passwords getting cracked quickly.

Finally, when you're in fact doing that post-valid() fuzzing, it might
make (a little) sense to patch those parts as well, to have the hashes
fake-cracked even quicker (such as in 100 ms instead of in 1 second).
But you're not there yet.

So we're all puzzled as to what you're trying to do now.  It just looks
very wrong to us.

I hope this helps, and I hope you re-focus your effort accordingly.

Thanks,

Alexander

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ