Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

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