[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 1 Jan 2013 23:30:09 +0100
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-dev@...ts.openwall.com
Subject: Re: A few questions regarding the newly added BLAKE2 format
On 01/01/2013 10:48 PM, magnum wrote:
> 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.
I do not insist. I am just unsure what the best solution is.
Knowing what formats *could* possibly crack a given hash also is an
important feature.
May be you are right, and it is more important to let the user know that
there are possibly more formats which could crack a given hash than
allowing him not to specify --format=, and still expect a raw hash to be
treated as raw-sha512.
> 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.
No, spending/causing effort for such crude workarounds is not what I
wanted, although, in this particular case it might be a bit unfortunate
that BLAKE2 would grab raw-sha512 hastes, even if BLAKE2 probably isn't
really used as a password hash function.
There might be users who will complain on john-users when they are not
longer able to crack raw-sha512 hashes if they forget the --format switch.
May be this really should have been discussed on john-users as well, so
tomorrow I'll try to get this discussed on john-users.
As developers, we could adjust at least some of the test vectors, adding
the "$SHA512$" prefix, plus a comment which indicates that this prefix
should be added to the raw hashes to make sure raw-sha512 format is used
to crack these hashes.
Instead of mentioning each individual raw format in a doc file, and
creating a raw<something>2john binary or script for each individual raw
format, may be a more general tool could be helpful.
This tool (probably a symbolic link to john, to reuse core john
functionality as well as format specific functions) should allow to read
an input file (or stdin), and extract all input lines with hashes that
are treated as valid by a given format, replacing the input hash with
the canonical hash representation before writing the line to stdout.
E.g.,
./extract-hashes --format=raw-sha512 < in-file > out-file
Doing this might not be trivial, because we could run into issues
similar to those we have with --show=LEFT (suppressing multiple lines
with the same hash...)
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.
