[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEvMK8fABe1PZqa1nSqe2Urcn=ubj1FLToUAVj42RZvEeb=eCQ@mail.gmail.com>
Date: Fri, 28 Aug 2020 12:13:27 -1000
From: Owein Douard <yvain29@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: rain mode
I think I got a little excited in my last messages, I don't want to let it
impact upon the alorithm that I found, which I consider to be a treasure
that belongs to many people whom I crossed path with.
And especially my relatives, I am going to work on my fork so that you can
just clone it, compile it, and see.
As for now I managed to use the nodes so option -fork is good.
I need to get the restore mode working and then I'll makena pull request
and leave the rest to you.
Opencl will soon be worthless, in a few years cpus will beat them in every
fields.
Going to rest, cu.
Owein.
On Fri, Aug 28, 2020 at 10:40 AM Owein Douard <yvain29@...il.com> wrote:
> Hi again, my tests results are not good if it is to show which of -inc or
> -rain mode cracks the most passwords in the shortest timespan.
> My lists of hashes are full of these passwords that you managed to predict
> with your method.
> Yet some of them will not appear (on a 30 minutes run) with -inc and do
> when using my mode.
> The point is that -rain should be defined as a 'hardcode/complex
> passwords' cracker, meaning unrealistic passwords or left out of -inc or
> markov logic which,
> when using a password manager or a piece of paper, are used. I desire to
> see this method included in john and using opencl, so that we could run it
> against lists of uncracked hashes from
> temp.hashes.org, and am certain that many of them would be found.
>
> I am ready to dedicate myself to this provided you can give me hints on
> some parts of the architecture of john which are unclear to me.
> If you need to do a comparison i suggest that we do so against the subsets
> module, which resembles slightly rain and is only two times faster.
>
>
> On Fri, Aug 28, 2020 at 4:43 AM Solar Designer <solar@...nwall.com> wrote:
>
>> Owein,
>>
>> Thank you for this additional detail.
>>
>> On Fri, Aug 28, 2020 at 04:13:05PM +0200, Owein Douard wrote:
>> > 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.
>>
>> That's not how incremental mode is normally used, except sometimes for
>> some short lengths where an exhaustive search can be done quickly.
>>
>> Normally, incremental mode is allowed to switch lengths back and forth,
>> and doesn't exhaust the full ASCII character set for the higher lengths
>> (several of them) that it ends up testing.
>>
>> > Then we should try this mode
>> > starting with the latter run's maximum length + 1. This would avoid
>> > duplicating.
>>
>> There wouldn't be that clear "maximum length + 1" in optimal usage of
>> incremental mode, however let's suppose we crippled incremental mode
>> (such as for ease of our further reasoning) by limiting it to some lower
>> maximum length. Say, we let it run for lengths up to 6 and exhaust that
>> space. Then we can either let it run for lengths 7+ or run rain mode
>> for lengths 7+ instead. Either of these won't be limited solely to
>> length 7 until exhausting it, but would try various passwords of length
>> 7 and above. Which one of these would crack more passwords in the same
>> amount of time? Can you test? My bet is on incremental.
>>
>> BTW, you don't actually need to exhaust length 6 to test the above - we
>> only need password counts for length 7+ for one mode vs. the other. So
>> you can only do the length 7+ tests, and we'll have our comparison.
>>
>> Please feel free to suggest and test this for another reasonable length
>> threshold as well.
>>
>> > 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 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.
>>
>> Please feel free to also test on the kind of hashes where you expect
>> rain mode to help. For example, you may take a list of mostly "laid
>> back passwords" (in your words) like RockYou and leave only the unique
>> passwords (not seen in there more than once).
>>
>> > 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.
>>
>> Found it:
>>
>> https://hashcat.net/forum/thread-9298.html
>> https://github.com/hashcat/hashcat/issues/1984
>>
>> > 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,
>>
>> Incremental mode doesn't need to exhaust the lengths one by one.
>>
>> > Regarding the algorithm itself, I think it can fill a gap between a very
>> > deep markov and a linear bruteforce.
>>
>> I think incremental mode already fills that gap.
>>
>> > 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.
>>
>> OK.
>>
>> 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.
