Date: Sat, 30 May 1998 20:32:04 +0200 From: Eivind Eklund <eivind@yes.no> To: "J.A. Terranson" <sysadmin@mfn.org> Cc: "freebsd-security@FreeBSD.ORG" <freebsd-security@FreeBSD.ORG> Subject: Re: MD5 v. DES? Message-ID: <19980530203204.34537@follo.net> In-Reply-To: <01BD8BC3.962CBD80@w3svcs.mfn.org>; from J.A. Terranson on Sat, May 30, 1998 at 12:07:57PM -0500 References: <01BD8BC3.962CBD80@w3svcs.mfn.org>
index | next in thread | previous in thread | raw e-mail
On Sat, May 30, 1998 at 12:07:57PM -0500, J.A. Terranson wrote:
> [=] I was not aware of the context (I was responding to
> "digested" 8-> form of the original message (having never
> seen the original) which did not make the context clear...
>
> Within this context, I would submit that DES is the "better"
> function, as it is not subject to "birthday" problems, I do realize
> however, in the *real* world, this is probably not a *real* issue...
I think you've misunderstood much of the basis here.
(1) EVERY hash function is subject to 'birthday' attacks. All of
them. It is _not_ possible to avoid. The question (if the hash
is cryptographically secure) is only one of key length.
(2) "Birthday" attacks are a real issue. They mean that hash-length
is effectively severely reduced for proving ID of a certain
document.
(3) They're absolutely not relevant for the present context, which is
one of password hashing. Passwords are supposed to go through a
good, paramterized one-way hash. The 'birthday' attack could be
used to create a password entry that could be used with two
different passwords. This is not a security problem.
Apart from that, my ideal hash for a password file is one based on
searching for public keys. It'd go like this:
(1) Salt the password
(2) Use a cheap one-way hash to create a start value for a
pseudo-random function (e.g, an LFSR)
(3) Use the random-function to do a deterministic search for a
public/private key pair
(4) Store the salt and the public part of the key as the hash
The advantage of this is that the stored password hash can be used to
do challenges against. We can determine that a client has the
password by sending a challenge consisting of some random data and the
salt. The client run through step 1 through 3 above, and then use the
private key to sign the data and return that to the server. Voila -
we've proved that the client has the password, without relealing
anything to the server (or any listeners). Much better than shared
secrets.
Eivind.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe security" in the body of the message
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980530203204.34537>