Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 5 Apr 2006 20:23:26 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: about salts

On Tue, Apr 04, 2006 at 11:07:47PM -0500, Dennis Olvany wrote:
> Would it not make sense to store the salts separately from the
> passwords?

Usually, no.

> Would it not be more difficult to crack the passwords without
> the salts?

Yes.  But the target system, when doing its usual user authentication,
would either have access to the salts or it would have to similarly
search the entire salt space.  In the former case, the salts could be
stolen along with the shadow password file - even if it would mean two
files to grab.  In the latter case, the hashing method would have to be
weakened in some other way (perhaps the iteration count reduced) in
order to keep the time needed to perform authentication sane.  Also, the
salt space would need to be kept small (which is undesired; modern
password hashing methods such as bcrypt use up to 128-bit salts) and
there would be timing leaks which would need to be dealt with.

> >With the traditional crypt(3), the first 2 characters of the
> >13-character encoding are the salt (12 bits, for 4096 possibilities).
> 
> The first two characters are salts in the plain, no? The hashes are
> ascii-encoded, no? I thought 2 ascii characters would be 16 bits.

The traditional crypt(3) only encodes 6 bits per character.  It couldn't
possibly use 8 bits per character as some characters are special - e.g.,
linefeeds and colons are special to the passwd file format.

> >>(Traditional DES [24/32 4K])
> 
> What the heck are these numbers, by the way.

They describe the algorithm used to implement a given hashing method in
this particular build of John.  In your case, the numbers say that the
algorithm uses 24 bits out of 32-bit machine words and that it uses 4 KB
large lookup tables in its inner loop.

For the MMX build, the algorithm description string would be "64/64 BS MMX",
meaning that 64 bits out of 64-bit MMX registers are used, this is a
"bitslice" algorithm (64 boolean expressions are being calculated in
parallel in different bit layers - instead of the use of lookup tables),
and indeed that MMX is used.

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

Your e-mail address:

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