Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 23 May 2006 06:31:41 +0400
From: Solar Designer <>
Subject: Re: John the Ripper development

On Mon, May 22, 2006 at 01:48:02PM +0200, Joschka Sulzer wrote:
> How about adding  features like describes ?

I'll start with a "generic" answer since I think you did not mean to
focus your question specifically on OpenMP.

This topic is being brought up every now and then.  People are
suggesting that I add parallel/distributed processing to John using one
of the many libraries/toolkits.  While this can be done and has been
done by others for fun or as a part of their academic career, it is not
great for practical uses of John.  You can see some bits from past
discussions here:

However, OpenMP is quite different.  It is a way to explicitly tell the
compiler what constructs may be parallelized/vectorized.  This is
reasonable and I do not rule out the possibility that I will enhance
John source code with OpenMP directives eventually, although I expect
that capable parallelizing compilers will detect parallelism in the
current bitslice DES code already - provided that DES_BS_VECTOR is set
high enough.  On "true" vector computers, this is the way to go
(although I'd imagine that vendor-specific and not OpenMP directives
would need to be used presently, if at all).

On non-vector multi-processor systems, I expect that an explicit
one-process-per-CPU model will provide better efficiency for John.  In
fact, separate CPUs might even be treated the same as separate nodes on
a network with no efficiency loss.  The task of password cracking does
not require frequent switches between sequential and parallel execution
that parallelizing compilers and OpenMP directives are great for.

Alexander Peslyak <solar at>
GPG key ID: B35D3598  fp: 6429 0D7E F130 C13E C929  6447 73C3 A290 B35D 3598 - bringing security into open computing environments

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ