[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060405200819.GA10482@openwall.com>
Date: Thu, 6 Apr 2006 00:08:19 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: about salts
On Wed, Apr 05, 2006 at 02:32:26PM -0500, Dennis Olvany wrote:
> I have a good idea of the function of salts. Wikipedia summed it up
> pretty well, "Since the salt is different for each user, the attacker
> can no longer use a single encrypted version of each candidate password."
>
> http://en.wikipedia.org/wiki/Password_cracking#Salting
Yes. Here's another reference:
http://article.gmane.org/gmane.comp.security.openwall.john.user/278
> Ok, I've got a good handle on base64 now. So, what's stored in the
> passwd file is a base64 encoding of the hash.
This doesn't really make a difference for our present discussion, but
for the sake of correctness I'd like to point out that the encoding is
"a base 64 encoding", not "the base64 encoding". "base64" is used to
refer to a very particular encoding scheme - that also uses 64 different
characters - but it is not exactly the encoding that crypt(3) uses.
> I've confused myself
> again, though. A 13 character encoding of which the first two characters
> are the salt. At 6 bits per character, that makes the salt 12 bits and
> the hash 66 bits. DES is 56 bits, no?
DES is a block cipher which encrypts 64-bit data blocks with 56-bit
keys. The traditional crypt(3) uses modified DES (with the support for
salting added right into DES itself, effectively making it not DES but
a DES-like cipher) on a block of all 0's (64 zero bits) - then it
repeats the modified-DES encryption 24 more times (for a total of 25)
taking the output of each iteration as the new input block. Finally,
the resulting 64-bit block is encoded to form the last 11 characters of
the crypt(3) output.
Yes, those 11 characters could also hold 66 bits, not just 64. It can
be said that the last character has two unused bits. Those bits are
always zero for valid crypt(3) outputs. In fact, John even uses this
knowledge to refuse to load about 75% of fake crypt(3)-hash-like strings
that some people produce without regard to this property. ;-)
> Possibly there is a resource that provides such details specific to
> password hashes. Something that maybe covers many hashes and details the
> salts and encodings.
For password hashes:
http://www.users.zetnet.co.uk/hopwood/crypto/scan/ph.html
For cryptographic algorithms in general:
http://www.users.zetnet.co.uk/hopwood/crypto/scan/
Unfortunately, this resource appears to be unmaintained since 2002 and I
failed to contact the author/maintainer with some corrections (my e-mail
bounced).
--
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.
