Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 10 Jun 2012 23:52:01 +0200
From: Frank Dittrich <>
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).


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.