Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BLU0-SMTP387C1C5570BE2F19719B16FDF80@phx.gbl>
Date: Mon, 18 Jun 2012 19:17:01 +0200
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Reduced binary size

On 06/18/2012 09:47 AM, magnum wrote:
> Obviously, get_source() will not be safe if we use a reduced (32 bits)
> binary. We might produce false positives, as we never really compare
> with the full original binary. These false positives will be "reset"
> (hashes will be regarded as remaining) on next run/resume of the hash,
> as the john.pot hash will not match the ciphertext. But it's still not
> acceptable. I see no way other than making these techniques mutually
> exclusive, unless someone has a clever solution (theoretically,
> get_source could re-read the original source from its file).

If you are going to retrieve the original hash from the file, this needs
to be documented somewhere.
Because currently, you can use

$ killall -s 1 john
$ ./john --show=LEFT input > input2
$ mv input2 input

and this will not cause any problem.
If those sessions that keep running access the changed input file to get
the original hash, this can cause all sorts of trouble.

Frank

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.