[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJ9ii1ESF6RggkcgeZ5xsqcd9AeKiiNn3MK_3Y8Fc6UPCSUJRw@mail.gmail.com>
Date: Tue, 5 Sep 2023 23:06:52 -0400
From: Matt Weir <cweir@...edu>
To: john-dev@...ts.openwall.com
Subject: Re: Implementing compatibility with the 3PC protocol
Hi Håvard,
First of all I want to say thank you for having your team present at
PasswordsCon. I was bummed I missed that presentation, so I'd also like to
thank you for posting your paper so I can read it! While I want to really
dig into that paper and have some questions, I probably need to read it
(vs. skim it) so I don't just waste your time. For now though I'd like to
dig into your request since I think it might align with something that has
been on my wishlist for a while: A dynamic hash mode that does partial
matches of the hash.
Backing up, it would be very helpful in a number of different use-cases to
say "only compare X bytes of the target hash, starting at byte Y", and then
output cracks that match that partial hash.
Use-Cases:
-- Vanity Hashes: Aka I want to have a hash that starts with "31337"
-- All those poorly formed or collected password files that have "junk" in
some of their positions (E.g: Original LinkedIn leak), or are partial
hashes themselves
Now Håvard, I realize this isn't a direct analogy to your vectors, but at
the same time it could dramatically cut down on the generated hashlist size
you'd need to create and check against if you didn't have to perform
cracking attacks against every possible combination generated by that
vector. So instead of 2^32 possible hashes for a single MD5 "submission"
you could only check half the hash and have 2^16 possible hashes that JtR
would need to load up. That's the number of hashes, not the keyspace,
(which would be 16^16) which should still be good enough to reduce false
positives. Worst case you have a two-pass system where you validate the
plaintext against the second half of the hash.
Admittedly, this doesn't get into the feasibility of implementing a partial
hash check dynamic mode, (Solar highlighted the design challenges), but my
real point is that this feature might be helpful for 3PC and it certainly
would be helpful in general for the other use-cases I mentioned.
Cheers,
Matt Weir
On Tue, Sep 5, 2023 at 5:03 PM Lukas Odzioba <lukas.odzioba@...il.com>
wrote:
> On September 5th 2023 at 21:22 Solar Designer wrote:
>
>>
>> You can manage to efficiently integrate this into individual formats for
>> a proof-of-concept or a specialized use case, but not easily integrate
>> it into JtR as a whole.
>>
>
> In general I agree with the above, but if the PoC is all you need and it
> should be fairly easy to figure out what to do, I would
> treat formats as a blackbox backend and create a new frontend with
> communication, candidate preparation and multithreading support.
> If you look how formats integrate with John you can use similar approach
> and connect calculating f(password, salt) to anything you want.
> GPU stuff would need more plumbing, but is doable. Such PoC frankenstein
> would be a separate binary living in John's source tree.
>
> Thanks,
> Lukas
>
Content of type "text/html" skipped
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.
