[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <8a684bb527c44543220b7446adc8dae6@smtp.hushmail.com>
Date: Wed, 25 Jun 2014 00:26:29 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: split vs prepare
Solar, Jim, all
I want this discussed, and "documented" here.
I think the following is granted: If you want to unify case of hex
hashes, you should do it in split() and declare FMT_SPLIT_UNIFIES_CASE.
But there are other things you can do in split() *or* in prepare(). And
there are things you simply can't do in split(). When/what should you
choose? Until now I always thought "if it CAN be done in split, it
should". Is this a correct approach? Does it matter?
In some tests today, when I added a tag in prepare(), untagged hashes in
a pot file would no longer be recognized as cracks for tagged hashes in
an input file. When I added the tag in split() instead, it worked
without this flaw. But did that depend on other things? I'm not sure.
Here's the order things happen (I think) when you load a hash for cracking:
"input line" -> prepare() -> valid() -> split() -> "source"
This "source" is what will be written to the pot file in case we crack
the hash - and binary() and salt() will be called with "source". But I'm
not quite sure how cracked hashes are found when loading a file. What is
really needed to recognize a .pot line which does not resemble an input
line?
In the NT format, which is among the best tested, we use both split()
and prepare():
* prepare() reads pwdump-style input and converts it to a "normal" hash
(including a tag, although I think that is not needed).
* split() adds a tag unless already present, and unifies case.
* valid() accept tagged or untagged hashes. As do binary()... is this
ever needed?
Please discuss!
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.
