[ On Wed, November 16, 1994 at 15:17:57 (CST), VaX#n8 wrote: ]
> Subject: Re: crypt(3)
>
> What about modifying the programs which do login-related password checking
> to use an intermediate interface, such that crypt() itself did not have to
> be replaced, but rather the "intermediate interface" could be re-written
> to use another crypt-like function?

But that's not really the problem.  The problem around here is that we
need portability of the encrypted data to older implementations, not
portability of the interface.

In an isolated environment, any encryption function could be substituted
for any of the uses of crypt(3), esp. password encryption.

However, crypt(3) input/output must remain compatible for files
encrypted with any utilities that do so, such as ed(1), and for password
entries in the case where these entries may be shared.

> Perhaps a libauth.a or auth.h or something is in order?  You could then put
> all the "knowledge" of the authentication mechanisms in there, and do all the
> #ifdef DES or #ifdef MD5 or #ifdef SHA's that you want.  And stuff that needs
> crypt() won't break.  And you can play with different (new) algorithms, etc.
> Or you can just keep it the way it is and use a compatible crypt.

So long as this is extensible to things like kerberose, etc., then it
should be acceptable.  Sites like ours would just build it all in
compatability mode.

-- 
						Greg A. Woods

+1 416 443-1734			VE3TCP		robohack!woods
Planix, Inc. <woods@planix.com>; UniForum Canada <woods@uniforum.ca>