Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 13 Jul 2012 04:32:17 -0500
From: "jfoug" <>
To: <>
Subject: RE: request for new dynamic subformats

I have re-gen salt working with the salt of ?d?d for a new ‘thin’ format made to use dyna-61:  sha256($s.$p).


Works fine when built under magnum-jumbo tree.  However, when built with magnum-bleeding, it does not find anything.


I have tested this with the other re-gen (an OSC file with the salts removed), and it does not find anything there either.  I think the new bitmap logic must short circuit out, and not allow rolling through all of the salts, which is what the re-gen code expects to happen.  Since I am not sure exactly what the bit-map code does, I have not figured out what is going wrong.  


However, in the crack loop, it only appears that one salt check is done, even though 100 salts were built into the salt list.   It also could be that the salt processing using that list has changed.  I really do not know, but the salt-regen code (as written), is not working properly on bleeding.  Oh well, moving on to the next set of crypts ;)




From: jfoug [] 
Sent: Thursday, July 12, 2012 8:04 AM
Subject: RE: [john-dev] request for new dynamic subformats


That is why the ‘regen-salt’ is so nice.   It rebuilds a ‘valid’ hash once found.  For a long time, I had used other techniques for finding lost salts, and yes, the editing after the fact to get the right hash/salt and the ‘real’ password was a pain.  That is why I built code to automate that in JtR.   


It will ONLY be useful for tiny very undersized salts (like original DES was, like early media wiki, etc), and it sounds like this is an ideal candidate (100 salts).




From: Elijah [W&P] [] 

It' ll definitely do, but what I dislike in this technique is the need to cleanup the .pot file due to the fact that salt and the pass will be combined.


On 11 July 2012 22:51, Francois Pesce <> wrote:



I've noticed that just appending ^[0-9] ^[0-9] to the dictionary rules make the job.

Wouldn't it be easier to implement a kind of "macro" parameter that allows a user to specify a rule or a set of rules to add to every rules? (i.e. john --macro-rule="^[0-9] ^[0-9]")


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.