[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200828132338.GA28726@openwall.com>
Date: Fri, 28 Aug 2020 15:23:38 +0200
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: rain mode
Hi Owein,
Thank you for offering to contribute this mode to our project!
On Fri, Aug 28, 2020 at 02:01:08AM -1000, Owein Douard wrote:
> Hello, from this thread on github
> <https://github.com/openwall/john/issues/4323> I was invited to join the
> mailing list, which I have done.
> I just understand that everything goes through email and appears here.
> Let me know about which address is correct to be able to communicate.
The address you sent the above to is correct.
We originally created the john-dev list for our participation in Google
Summer of Code, which we did a few times. The list became mostly
inactive since then, but it's OK to use it again for this discussion.
As you asked, I took a look at your https://github.com/e2002e/zhou repo
and at your fork of john. My first question, which I couldn't find an
answer to, is what the rationale for the proposed rain mode is. Can you
perhaps answer this in here? When is this mode to be used, why, and
what advantage it'd provide over other modes. Any examples you might
have of this mode cracking real-world passwords (e.g., use RockYou) or
at least real contest passwords (e.g., from KoreLogic's CMIYC contests)
that other modes didn't when run for the same amount of time.
I think we need to test rain vs. the current incremental mode with dummy
.chr file generated from fake john.pot containing just ":charsethere"
all on one line, and see which cracks more passwords e.g. of RockYou,
optionally after having ran some other modes (e.g., wordlist with
rules). Can you do that? If there's another use case you propose your
mode for, then can you make a similar comparison for that use case?
Trying to see what's good about rain mode, I arrive at these 3 points:
1. Length switching back and forth like in incremental mode, but with
charset specified via the command-line like in mask mode. Maybe we need
to reintroduce a revision of incremental mode similar to what we had
back in JtR 1.0, where a charset can similarly be specified directly.
2. Trying to win a maybe unfair (non-random) lottery by trying randomish
combinations instead of sorting by assumed probability (maybe unknown)
or trying combinations in a more obvious sequence (which might not have
a chance of hitting the particular unfair lottery's non-random pattern).
While this might feel intuitive, I think it doesn't improve the chances.
I wrote some related thoughts here:
https://www.openwall.com/lists/john-users/2020/04/12/1
and earlier in that thread.
3. Like 2, but assuming you or others are also trying or have previously
tried the more obvious sequences. Now this makes some sense, but then
if rain mode becomes widely available the same issue of further need to
randomize your attempts vs. others' will arise. If that's the use case,
maybe we can come up with something that fits it even better?
Regardless, you also brought up questions on adding a cracking mode to
JtR in general - specifically, on getting "--restore" and fork/node/MPI
support to work right. Ideally, we'd gain documentation that would be
reusable by you and others wanting to add a cracking mode in the future.
We may discuss that even if your specific rain mode isn't to be added.
Another observation I have is that rain mode looks simple enough to have
it as an external mode, at least initially. Obviously, that would be a
worse fit for cracking fast hashes (like raw MD5 and SHA-1 in zhou), but
it'd make the algorithm's logic apparent before we clutter it with
multi-node implementation detail, etc.
Thanks,
Alexander
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.
