[1009] in Kerberos

home	help	back	first	fref	pref	prev	next	nref	lref	last	post

Re: Why is initial user authentication done the way it is?

daemon@ATHENA.MIT.EDU (smb@ulysses.att.com)
Fri Jun 15 09:58:39 1990

From: smb@ulysses.att.com
To: "Jonathan I. Kamens" <jik@PIT-MANAGER.MIT.EDU>
Cc: kerberos@ATHENA.MIT.EDU
Date: Fri, 15 Jun 90 08:49:35 EDT

	 3. The crypt() function under Unix is meant to be slow.  Kerberos'
	    decryption of the tgt is faster, significantly.

You've fallen into the trap that you were intended to fall into.  Crypt()
was *coded* to be slow, in the hope that naive crackers would use it instead
of rewriting it.  Apart from the E-box juggling, crypt() is straight DES.
You could copy most of the code from Kerberos.  You could even save time
by precomputing all 4K E-boxes.  The speed issue boils down to who is
doing the most encryptions.  crypt() iterates 25 times; however, the
initial permutation and its inverse, when composed together, are the
identity permutation; thus, they can be omitted.  And they're one of
the slowest parts of software DES.  If you're not repeatedly encrypting
the same string in DES, you can't do that optimization.  I'd call it
a wash on speed.

	    Furthermore, it's
	    straight DES, so anyone who is serious about cracking passwords can
	    use all of the available DES hardware to do his cracking.

Not clear that that actually works here.  The strings are comparatively
short, as I recall, and the setup time for DES hardware can be significant.
This is especially true if you're using a UNIX system and have the OS and
device driver overhead.  A dedicated PC with a DES chip wouldn't have as
much overhead, of course.

home	help	back	first	fref	pref	prev	next	nref	lref	last	post