From owner-freebsd-current  Mon Dec 16 07:20:48 1996
Return-Path: <owner-current>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id HAA11705
          for current-outgoing; Mon, 16 Dec 1996 07:20:48 -0800 (PST)
Received: from haywire.DIALix.COM (news@haywire.DIALix.COM [192.203.228.65])
          by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id HAA11698
          for <freebsd-current@freebsd.org>; Mon, 16 Dec 1996 07:20:43 -0800 (PST)
Received: (from news@localhost) by haywire.DIALix.COM (8.8.4/8.8.2) id XAA21550 for freebsd-current@freebsd.org; Mon, 16 Dec 1996 23:20:34 +0800 (WST)
X-Authentication-Warning: haywire.DIALix.COM: news set sender to usenet-request@haywire.dialix.com using -f
Received: from GATEWAY by haywire.DIALix.COM with netnews
	for freebsd-current@freebsd.org (problems to: usenet@haywire.dialix.com)
To: freebsd-current@freebsd.org
Date: 16 Dec 1996 15:20:33 GMT
From: peter@spinner.DIALix.COM (Peter Wemm)
Message-ID: <593pc1$k40$1@haywire.DIALix.COM>
Organization: DIALix Services, Perth, Australia.
References: <199612152022.PAA05216@skynet.ctr.columbia.edu>
Subject: Re: Plan for integrating Secure RPC -- comments wanted
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

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