Ami Schwartzman | 2 May 11:04 2006
Picon

Tuning John

Hi everybody,

A few questions:

1) What is the performance gain (if any) by moving john on linux-x86-mmx 
to linux-64-x86-mmx  for Intel processors?

2) Why does the CYGWIN and DJGPP versions do not calculate virtual c/s 
in the benchmark, and in general how does John calculate virtual c/s?

3) If we will need to migrate a version of John to MS Visual C++, which 
version should be the easiest to do?

Thanks, Ami.

--

-- 
To unsubscribe, e-mail
john-users-unsubscribe@... and reply
to the automated confirmation request that will be sent to you.

Solar Designer | 2 May 14:09 2006

Re: Tuning John

On Tue, May 02, 2006 at 11:04:25AM +0200, Ami Schwartzman wrote:
> 1) What is the performance gain (if any) by moving john on linux-x86-mmx 
> to linux-64-x86-mmx  for Intel processors?

There should be no performance difference between the linux-x86-mmx and
linux-x86-64-mmx targets.  The only difference is that the former is
for 32-bit Linux/x86 distributions, whereas the latter is for 64-bit
Linux/x86-64 ones that have 32-bit compatibility libraries installed.
Both will use MMX for effective 64-bitness in exactly the same way.

The target which actually produces different code is linux-x86-64.  It
uses native x86-64 instructions instead of MMX.  In practice, the
performance is similar to that of MMX - although it may be 20% worse or
10% better for different hash types, CPUs, and gcc versions.

> 2) Why does the CYGWIN and DJGPP versions do not calculate virtual c/s 
> in the benchmark,

For Cygwin builds, that's because virtual (processor) times are not
available on Windows 9x and I did not bother implementing a (trivial)
check for 9x vs. NT.

For DJGPP builds, that's because processor times are supposed to match
real times (DOS is not a multi-tasking OS), and when they don't it is
not certain what host OS is used to emulate DOS and how it might report
processor times to DOS applications (if at all).  Not that I would
bother implementing this even if it were supported.  The DOS build is
for plain DOS.

> and in general how does John calculate virtual c/s?
(Continue reading)

Guillaume Arcas | 2 May 14:18 2006
Picon

JtR & NTLMv2 passwords

Hi.

I'm a bit confused about the ability of JtR to crack Windows passwords that use
NTLMv2 format.

Does anyone have some explanation or answer about that ?

Thanks & regards,

Guillaume Arcas - [http://yom.retiaire.org]
-----------------------------------------------------------
"Je cherche un ailleurs, mais pas trop loin d'ici." (Sempé)

--

-- 
To unsubscribe, e-mail
john-users-unsubscribe@... and reply
to the automated confirmation request that will be sent to you.

xnix | 2 May 14:23 2006
Picon

SMP support (x86_64)

I have A64X2 and want to run JtR on both processors, I read manuals, but 
did'nt find anything about that.

--

-- 
To unsubscribe, e-mail
john-users-unsubscribe@... and reply
to the automated confirmation request that will be sent to you.

Michal Luczaj | 2 May 14:26 2006
Picon

MinGW build (was: Tuning John)

Solar Designer wrote:
> Maybe it would be a little bit easier for you to start hacking with the
> MinGW build patch, currently available as john-1.7-mingw-2.diff.gz in
> the contrib/win32/mingw/ FTP directory.

And, by the way, I've tuned it up a little (so now the patch is event
uglier and dirtier) to support real/processor time measurements. The 3rd
revision is at
http://www.pjwstk.edu.pl/~s3443/jasiu/john-1.7.0.2-mingw-3.diff.gz .
But, of course, no one is sure if it works the way it should ;)

Solar, I would be very grateful if you could put this in contrib/ as
well. pjwstk.edu.pl is just a temporary storage place, files there won't
last long.

Thanks,
Michal

--

-- 
To unsubscribe, e-mail
john-users-unsubscribe@... and reply
to the automated confirmation request that will be sent to you.

rembrandt | 2 May 14:35 2006
Picon

Re: SMP support (x86_64)

> I have A64X2 and want to run JtR on both processors, I read manuals, but
> did'nt find anything about that.

processors -> Cores

Run john twice... with different inputs...
And no there´s no other solution.

Rembrandt :-D

--

-- 
To unsubscribe, e-mail
john-users-unsubscribe@... and reply
to the automated confirmation request that will be sent to you.

Solar Designer | 2 May 16:52 2006

Re: JtR & NTLMv2 passwords

On Tue, May 02, 2006 at 02:18:13PM +0200, Guillaume Arcas wrote:
> I'm a bit confused about the ability of JtR to crack Windows passwords that use
> NTLMv2 format.

This question itself is confusing.

My (limited) understanding is that NTLMv2 is a revision of the NTLM
authentication protocol as described, for example, here:

	http://davenport.sourceforge.net/ntlm.html

However, even when NTLMv2 is in use, the underlying password hashes
that are stored on Windows systems are plain NTLM, not NTLMv2 (there's
no such thing as an NTLMv2 password hash; instead, there are NTLMv2
challenge responses).

JtR supports LM and NTLM hashes (the latter with the contributed patch)
that are stored on Windows systems.

JtR does not support sniffed NTLM protocol challenge/response pairs.

-- 
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

--

-- 
To unsubscribe, e-mail
(Continue reading)

Guillaume Arcas | 2 May 17:06 2006
Picon

Re: JtR & NTLMv2 passwords

Selon Solar Designer <solar@...>:

> This question itself is confusing.
>
> My (limited) understanding is that NTLMv2 is a revision of the NTLM
> authentication protocol as described, for example, here:
>
> 	http://davenport.sourceforge.net/ntlm.html
>
> However, even when NTLMv2 is in use, the underlying password hashes
> that are stored on Windows systems are plain NTLM, not NTLMv2 (there's
> no such thing as an NTLMv2 password hash; instead, there are NTLMv2
> challenge responses).
>
> JtR supports LM and NTLM hashes (the latter with the contributed patch)
> that are stored on Windows systems.

Thanks, that exactly what I wanted to know/understand more clearly.

Regards,

Guillaume Arcas - [http://yom.retiaire.org]
-----------------------------------------------------------
"Je cherche un ailleurs, mais pas trop loin d'ici." (Sempé)

--

-- 
To unsubscribe, e-mail
john-users-unsubscribe@... and reply
to the automated confirmation request that will be sent to you.

(Continue reading)

Solar Designer | 2 May 17:05 2006

Re: SMP support (x86_64)

On Tue, May 02, 2006 at 04:23:40PM +0400, xnix wrote:
> I have A64X2 and want to run JtR on both processors, I read manuals, but 
> did'nt find anything about that.

This is addressed in the following FAQ entry:

Q: Does John support multi-processing or distributed processing?
A: There's no real MP or distributed processing support in John right
now, but you can distribute the work between a few nodes manually.  One
approach would be to have your nodes (CPUs, machines) each try different
password lengths.  This is easily accomplished with "incremental" mode's
"MinLen" and "MaxLen" settings (see CONFIG).  Typically, you would not
really need to split the work for "single crack" and wordlist modes
since these are relatively quick, although you may dedicate one node to
those initially.  You may safely run multiple instances of John in the
same working directory, all writing to the same "pot file" (this is a
feature).  You do, however, need to assign each of them a unique session
name, with "--session".  Other approaches, such as splitting password
files naively (without regard to salts), are typically less efficient
(in some cases to the extent where there's no speedup from using
multiple processors at all).

Also, this topic has been discussed on this mailing list before:

	http://article.gmane.org/gmane.comp.security.openwall.john.user/105/
	http://search.gmane.org/?query=trivial+parallel+processing&group=gmane.comp.security.openwall.john.user
	http://marc.theaimsgroup.com/?l=john-users&m=112491291020241
	http://marc.theaimsgroup.com/?t=112491292700007

--

-- 
(Continue reading)

Solar Designer | 2 May 17:22 2006

Re: MinGW build (was: Tuning John)

On Tue, May 02, 2006 at 02:26:29PM +0200, Michal Luczaj wrote:
> Solar Designer wrote:
> > MinGW build patch, currently available as john-1.7-mingw-2.diff.gz in
> > the contrib/win32/mingw/ FTP directory.
> 
> And, by the way, I've tuned it up a little (so now the patch is event
> uglier and dirtier) to support real/processor time measurements. The 3rd
> revision is at
> http://www.pjwstk.edu.pl/~s3443/jasiu/john-1.7.0.2-mingw-3.diff.gz .
> But, of course, no one is sure if it works the way it should ;)

Well, you're still using the return value from clock() to emulate the
return value of times().  According to POSIX.1-2001, clock() "shall
return the implementation's best approximation to the processor time
used by the process ...", whereas times() "shall return the elapsed real
time ..."  So this patch looks wrong to me.

In my understanding, the problem with all revisions of your MinGW build
patch so far is that they report processor times (and virtual c/s rates)
in place of real times (and actual c/s rates).

> Solar, I would be very grateful if you could put this in contrib/ as
> well.

It's there:

	ftp://ftp.openwall.com/pub/projects/john/contrib/win32/mingw/

--

-- 
Alexander Peslyak <solar at openwall.com>
(Continue reading)


Gmane