Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 1 Jan 2013 22:48:11 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: A few questions regarding the newly added BLAKE2 format

On 1 Jan, 2013, at 21:56 , Frank Dittrich <frank_dittrich@...mail.com> wrote:
> On 01/01/2013 09:12 PM, magnum wrote:
>> My personal opinion is that we should definitely accept untagged hashes, of course provided that the length and charset is correct. We have this very good feature where John tells us what formats could be using the hash. To make an input file automatically pick a certain format, add tags in the file with a trivial sed one-liner. Or just supply the --format option. On a related note, I think we should always add tags to john.pot (and this format do) unless the hash format is odd enough to be easily recognized even with future in mind. I'd really like to hear other's opinions too, including but not limited to Solar. And the john-users crowd too btw.
> 
> My main concern here is that, especially with plugged-in-formats, you
> never know how the sequence of formats will be changes, so that hashes
> which now are treated as raw-sha512, will tomorrow be treated as
> something different (e.g., BLAKE2).

I'm not sure this is really a problem and if it is, I do not think rejecting raw hashes is a good solution at all. Note that if you have an old session that auto-picked raw-sha512 it will have the --format=raw-sha512 syntethically added to the .rec file so a resumed session will *not* have any problems. This is an important feature, already implemented.

What we could do if you insist, is force raw-sha512 to load before blake. Either by renaming one of the source files so the plugin globbing will put them in a different order, or by making raw-sha512 a non-plugin.

>> Second, the dynamic format currently does not seem to accept *any* untagged hash until you set DynamicAlwaysUseRawHashes=Y in john.conf. But if you do, dynamic seem to get too greedy, even accepting this 128 character hash as raw-md5! I am not quite sure how it is supposed to work: Maybe the current behavior is on purpose and it would only use the first 32 characters of that 128 char hash for eg. raw-md5? If that's it, I would prefer dynamic to accept it as dynamic_80 with that option turned off. But that is up to Jim to decide, I know dynamic is very complicated.
> 
> The dynamic formats also accept these hashes when using
> --format=dynamic_0 (or dynamic_2, dynamic_3, dynamic_19, ...).

You are right. Here is a normal md5 hash written twice:

$ echo 8ad8757baa8564dc136c1e07507f4a988ad8757baa8564dc136c1e07507f4a98 >test
$ ../run/john test -form:dynamic_0
Loaded 1 password hash (dynamic_0: md5($p) (raw-md5) [128/128 SSE2 intrinsics 10x4x3])
test3            (?)
guesses: 1  time: 0:00:00:00 DONE (Tue Jan  1 22:10:20 2013)  c/s: 360000  trying: 3533 - sierra

Even worse, the overlong hash is stored in john.pot:
$ cat ../run/john.pot 
$dynamic_0$8ad8757baa8564dc136c1e07507f4a988ad8757baa8564dc136c1e07507f4a98:test3

And that has this effect:
$ ../run/john test -form:dynamic_0 -show
0 password hashes cracked, 1 left

> IMHO, only raw hashes with the correct length should be treated by
> dynamic formats.
> But may be Jim can explain why this is actually a feature, not a bug.

I consider it a bug until then. The john.pot line is definitely a bug.

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.