|
Message-ID: <aa94bad0-6c6d-8e81-1cb6-00b9b91b2174@matlink.fr> Date: Fri, 4 Nov 2016 16:00:30 +0100 From: matlink <matlink@...link.fr> To: john-users@...ts.openwall.com Subject: Re: John does not fork as many times as I want Le 04/11/2016 à 15:56, Solar Designer a écrit : > On Fri, Nov 04, 2016 at 03:48:42PM +0100, matlink wrote: >> Le 04/11/2016 ? 15:40, Solar Designer a ?crit : >>> It's just a matter of >>> getting the weakest passwords out first, at which point you restart and >>> can run more processes due to them staying more similar to each other >>> for longer. If at some point they become dissimilar enough to run out >>> of memory again, you can interrupt and restore that session (without >>> losing any work already done). >> Understood. I suppose that using "john --restore=mysession" is faster >> than running again the above command having "--session=mysession", even >> if that command specifies a potfile ? > Sure, "--restore" continues from where the session was interrupted, not > re-testing the previously tested candidate passwords. > > Without that option, you have JtR re-test the same candidate passwords. > > The pot file eliminates previously cracked hashes in either case. Well, I was not using the --restore option, but always the --session with --pot and in fact, when john starts it says "Remaining 25185227 password hashes with no different salts" which is less than when previously ran. I guess --restore is equal to running john with the same parameters as before. That was my question. > > (Strictly speaking, even with "--restore" some candidate passwords may > be re-tested, because of buffering and such, so my "without losing any > work" is technically incorrect. However, in practice when cracking > raw-SHA1 hashes you won't notice this, except in "single crack" mode, > because it'd be a fraction of a second.) > > Alexander -- Matlink - Sysadmin matlink.fr Sortez couverts, chiffrez vos mails : https://café-vie-privée.fr/ XMPP/Jabber : matlink@...link.fr Clé publique PGP : 0x186BB3CA Empreinte Off-the-record : 572174BF 6983EA74 91417CA7 705ED899 DE9D05B2
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.