[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BLU0-SMTP109234A11BB0B7768788D75FDF00@phx.gbl>
Date: Sun, 10 Jun 2012 23:52:01 +0200
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Patch: allow --markov=SECTION in addition to --markov[=[MIN_LEVEL-]LEVEL[:START[:END[:[MIN_LENGHT-]LENGTH]]]]
On 06/10/2012 11:23 PM, Simon Marechal wrote:
> On 06/10/2012 08:51 PM, Frank Dittrich wrote:
>> I could understand if all these examples would produce the same number
>> of words. I would just have assumed that you don't want to check for
>> each single word whether the required number of words has been created.
>> But then, all these examples should have created 11 or 12 words.
>>
>> Do I have to dig into the source code if I want to find out what's going on?
>
> Actually this is the only way I found to achieve a decent speed. If you
> compute each password using the proper algorithm, you will have to
> compute each words letters at every step. By using a recursive generator
> it achieves much better performance, but it only realises it should stop
> when it goes out of some loop. This means it produces more passwords
> than expected at the beginning and end of the runs. It SHOULD only be
> hundreds of passwords too much, and SHOULD NOT be less passwords than
> expected. I thought about this when I wrote it, but I am not so
> confident today ;)
OK, for fast (especially saltless) hashes, this shouldn't matter too much.
I think the behavior should be documented somewhere in doc/MARKOV,
otherwise people might start to wonder (or even don't trust Markov mode
at all, due to the unexpected behavior).
Frank
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.
