[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEvMK8eaZhM260hOuPJH6xLkycrFQVy=tw7NTGq2w6kEyY7WDg@mail.gmail.com>
Date: Fri, 28 Aug 2020 16:13:05 +0200
From: Owein Douard <yvain29@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: rain mode
Alexander, to answer your question that is why and when to use rain mode,
I'd say after incremental mode has been run with a maximum length bound
that allows a
full ascii character set to be exhausted. Then we should try this mode
starting with the latter run's maximum length + 1. This would avoid
duplicating.
In general, the rain mode is not meant to be used against 'laid back
passwords', where users did not really care about their security because
they were eager
to access the service or wanted something easy to remember, but against
complex keys that are utterly unpredictable.
I wrote a post on the forum of hashcat where I was introducing zhou as a
'last resort cracking utility', and that is how the combination of the
algorithm and of the alternation of all the lengths should be used.
It's rare (for what I've seen) to find a truly long password, but when it's
the case, even though it be a simple one, the fact that we need to exhaust
the length one by one will make the task impossible,
Regarding the algorithm itself, I think it can fill a gap between a very
deep markov and a linear bruteforce. Patterns that appear are once simple
once complex, I have not found any other way to express that than calling
it rain,
but maybe the word skyzo (skyzo = shattered) suits.
Regarding the 3d note you made, the only thing that can be done to
randomize the algorithm is to randomize the starting value for the variable
'rain', and wrap around the total expected, starting back to zero. It works
well. I tried it before.
I am going to do these tests you asked for in a few hours from now and will
let you know, but my hashes are simples and you should expect incremental
mode to be the winner, but rain mode to find the long passwords before.
Regards.
Owein.
On Fri, Aug 28, 2020 at 3:24 PM Solar Designer <solar@...nwall.com> wrote:
> 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
>
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.
