Date: Fri, 2 Jun 2006 18:27:14 +0400 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: Re: beta MPI john patch against 1.7.2. On Fri, Jun 02, 2006 at 08:42:24AM +0200, Otheus (aka Timothy J. Shelling) wrote: > User notes: "the john.conf provied should be *incorporated* into your > john.conf." > SHould I maybe provide a patch to john.conf in this case? Yes, your changes to john.conf should be a part of the patch. In fact, the *.diff that I made public includes your john.conf changes in it. > >> Known bugs: > >> o john.pot gets littered with extraneous output, usually low integers > >> like "4" or "1" and a newline. ... > >My previous guess (from the private e-mail) proves correct - you do in > >fact close stdout and stderr in your patch. ... > I knew you would bring this up --it's a red herring. I added that code only > late last night ... OK, but that code is wrong. You should at the very least consider using dup2() instead of dup(). > >You can't reasonably speak of speedups/slowdowns by a certain percentage > >unless you mention the hash type and the number of different salts for > >which you did your benchmarks. > > --incremental mode, salted DES3. What's DES3? You probably mean the traditional DES-based crypt(3). And you haven't mentioned the number of different salts. I am not really asking you to provide all that information. I merely point out that it doesn't make sense to mention specific speedup/slowdown percentages without including that info as well. > Is there a function which rebuilds the database using the new > john.pot file There's ldr_load_pot_file(). A call to it must be followed by a call to ldr_fix_database(). Both of these were only meant to be called at startup, so I am unsure whether they'd work right from within a running session - that would require a code review and testing. With large "pot files" and/or a lot of password hashes loaded, this reload/rebuild may be rather costly, although hash tables are being used to make it faster. You can expect 10 seconds for 100,000 hashes or so. > and restarts the word--generation, etc? I don't think you need to "restart word generation", but you need to ensure that you do the database rebuild from outside of loops that depend on the database to remain constant. Perhaps doing it at the beginning of crk_salt_loop() is safe, but I did not verify that. Indeed, you need to rate-limit this and also check for the database possibly becoming empty. -- Alexander Peslyak <solar at openwall.com> GPG key ID: B35D3598 fp: 6429 0D7E F130 C13E C929 6447 73C3 A290 B35D 3598 http://www.openwall.com - bringing security into open computing environments Was I helpful? Please give your feedback here: http://rate.affero.net/solar
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.