Skip site navigation (1)Skip section navigation (2)
Date:      16 Dec 1996 15:20:33 GMT
From:      peter@spinner.DIALix.COM (Peter Wemm)
To:        freebsd-current@freebsd.org
Subject:   Re: Plan for integrating Secure RPC -- comments wanted
Message-ID:  <593pc1$k40$1@haywire.DIALix.COM>
References:  <199612152022.PAA05216@skynet.ctr.columbia.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
In article <11680.850740486@critter.tfs.com>,
	phk@critter.tfs.com (Poul-Henning Kamp) writes:
> Put DES in the kernel.
> 
> 	This could be as an LKM, which would be the easiest, or as
> 	a proper kernel-source file, which would be slightly harder
> 	to manage distributions-wise.
> 
>     Result:
> 	* You avoid your planned hack.
> 	* We could do away with the two versions if libcrypt we have
> 	  now, and collapse them into one.
> 	* Which makes the dual versions of /bin/ed, /sbin/init ... 
> 	  unneeded.
> 	* Our secure dist would consist of only the LKM file.

Why don't we just give in and make a dual-mode libcrypt with the
exportable des one-way hash code like all the other vendors are doing?
(and of course, the MD5 hash code)

For the spectators..  The original implementation of password encryption
used DES to encrypt block of data (8 zero's from memory) 25 times using
the text password as a key.  The problem was that this code used the generic
DES routines which were full encryption/decryption code.

Somebody designed a "broken" version of DES that purely became a 1-way hash
function (exportable, just like md5) that had no chance of being "converted"
to encrypt/decypt data (which would make it export restricted).

There is a difference between encrypting a known block of data to a result
that can be decoded back to the original data, and irreversibly hashing a
key (ie: password) in a way that comes up with the same results as the
"encrypt a block of nulls" method.

Anyway, the problem then becomes..  How do you choose the default encryption
type for the new merged crypt() when it doesn't have a precedent to go on?

I know this doesn't have much to do with Secure RPC, but it would get rid of
the dual versions of /sbin/init, /bin/ed, libcrypt etc.  I would like libcrypt
to go away and become a stub library just like libresolv/libgnumalloc.

-Peter



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?593pc1$k40$1>