Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 13 Jul 2012 06:18:29 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: XSHA_fmt_plug.c should support hashes in lower-case

Dhiru -

On Thu, Jul 05, 2012 at 03:57:27PM +0530, Dhiru Kholia wrote:
> I tried running john on hash
> "3e8ed8fc0c6ac6c17cb6efcbe43bf31e765f8f456b2a6500" but it wouldn't
> accept the hash. After doing echo
> 3e8ed8fc0c6ac6c17cb6efcbe43bf31e765f8f456b2a6500 | tr "a-z" "A-Z" >
> newhash, john happily cracks the newhash.
> 
> Is this by design or is it a bug / limitation?

It is by design, for two reasons:

1. To have fewer false positives on this format's valid().  IIRC, these
hashes are stored as all-uppercase on OS X.  Why is yours all-lowercase?
Where did you get it from and how?

2. Out of laziness, since we'd have to implement split() converting to
all-uppercase and set FMT_SPLIT_UNIFIES_CASE to support
non-all-uppercase hash encodings correctly.

Similarly, for XSHA512 we accept only all-lowercase, although in that
case the first reason above does not apply (the system does not store
these hashes as hex).  Perhaps we actually need to do the split() and
FMT_SPLIT_UNIFIES_CASE thing for XSHA512.  As to XSHA, I am not sure -
I'd like to hear your story first.

If in some other formats you support hex-encoded hashes without the
all-lowercase or all-uppercase restriction and you don't have split()
unify the case or/and you don't have the flag set, that's a bug, which
may result in misbehavior of the loader and especially of --show when
differently-looking instances of the same hash are present.

Alexander

Powered by blists - more mailing lists

Your e-mail address:

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