[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 6 Aug 2019 07:24:31 -0400
From: Matt Weir <cweir@...edu>
To: john-users@...ts.openwall.com
Subject: Re: Truncated hashes with DYNAMIC mode
Thanks for the reply magnum,
We can certainly move this discussion to a git repo issue as that's
probably more appropriate. In my head I was thinking of an option in
dynamic mode to only use a portion of a generated hash for future
computations or checks. That way it wouldn't need to be aware about the
cleartext guesses, (as they would be generated by a normal JtR cracking
session), nor would it be concerned with doing any "searching" for the
values, since it would just truncate the generated hash and then compare it
to the targeted hashes supplied by the user. Going this route would mean
that in the future we could also use this feature to quickly support
weird/broken formats like the original LinkedIn hashes which had a number
of leading 0's overwriting the start of the hash. Aka it'd be up to the
user to clean up their target hash list (for example cut off the leading
0's), but then they could use dynamic mode to truncate the hashes JtR
generates in a similar manner before doing a comparison.
Cheers,
Matt
On Tue, Aug 6, 2019 at 6:11 AM magnum <john.magnum@...hmail.com> wrote:
> On 2019-08-02 16:42, Royce Williams wrote:
> > On Fri, Aug 2, 2019 at 5:29 AM Solar Designer <solar@...nwall.com>
> wrote:
> >
> >> On Wed, Jul 31, 2019 at 11:22:22AM -0400, Matt Weir wrote:
> >>> I'm looking for a way to utilize dynamic mode to generate vanity
> hashes.
> >>> For example, finding a raw-MD5 hash that starts with '12345'. I've been
> >>> looking through the documentation for dynamic, but I'm missing how to
> >> only
> >>> check a subset of the final hash vs the target. Is that possible, and
> how
> >>> would I go about doing that? Bonus points if I can utilize the command
> >> line
> >>> dynamic expressions.
> >>
> >> I'm afraid this isn't supported, but I'd like JimF to confirm this and
> >> consider adding such functionality.
> >>
> >
> > That would be fantastic! I've long argued that such searching, if done
> in a
> > way that is low overhead for the maintainers of the tool (who are usually
> > not me, since my programming skills are limited), belong in the cracking
> > suites themselves rather than reinvented poorly or narrowly in other
> > frameworks. Of course, I understand that non-specialization also means
> that
> > some optimization opportunities must be discarded, so I also support
> > dedicated external tools when executed well. But I think that having this
> > in dynamic mode would be worth the trade-off.
>
> Well you could open an issue for it for RFC/discussion. For example, how
> would we format the input? Would we always want hashes that starts with
> "deadbeef" or sometimes only ends with it, or any of them? Or even
> "deadbeef" somewhere/anywhere in it (that would likely be awfully slow)?
>
> Also, would we want the cleartext that produces such vanity hash to be a
> printable one actually usable as a password, or more or less any binary?
> As mentioned recently, binary brute-force hasn't been within our scope
> but we're considering changing that.
>
> 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.
