Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [day] [month] [year] [list]
Date: Wed, 19 Apr 2006 16:18:53 +0200
From: "Erastus, Licky" <>
To: <>
Subject: RE:  specify individual salt to run

Can you send me the software

Tel: (+26461) 2012989
Cell: (+264811) 281015
Fax: (+26461) 258510 
Mobile Email:

"Why compare yourself with others? No one in the entire world can do a better job of being you than you." 

-----Original Message-----
From: Solar Designer [] 
Sent: Wednesday, April 19, 2006 3:54 PM
Subject: Re: [john-users] specify individual salt to run

On Wed, Apr 19, 2006 at 12:13:45PM +0000, -. -PhanTom-. - wrote:
> Was wondering if you would consider adding another command to jtr to let users 
> specify which salt to run?
> So that one could run only the hashes that has a specific salt?
> e.g 
> john --salt2:et ...

This had been considered before.  There are some good reasons to not
implement it:

1. In order to know what salts there are and which ones you want (or
don't want) to crack, you have to review the input password files and/or
john.pot manually.  If you do that, it should not be hard for you to
pass your files through grep or the like, eliminating the need for this
option to John.

2. The ASCII representation of salts is different for each hash type.
Would the documentation need to be complicated with instructions on how
to specify salts - e.g., whether to include or omit the "$1$" before
FreeBSD-style MD5-based crypt(3) salts?

3. I like to keep the list of command-line options reasonably short.

There's also a subtle reason in favor of implementing this:

With some hash types, there are multiple ASCII representations which
correspond to the same salt value.  If you include all hashes with the
traditional crypt(3) salt represented as "et", you likely also want to
include whatever other hashes might happen to have the same salt value
(since they can be processed at no additional cost), even if it is not
encoded as "et" (those other encodings are invalid, but nevertheless
they are sometimes seen in practice).  John can implement logic like
that, whereas grep won't do it.

On the other hand, someone might be surprised by this effect and even
find it undesirable.

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

Was I helpful?  Please give your feedback here:

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

Powered by blists - more mailing lists

Your e-mail address:

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