From owner-freebsd-hackers Thu Aug 29 14:27:06 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA06352 for hackers-outgoing; Thu, 29 Aug 1996 14:27:06 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA06346 for ; Thu, 29 Aug 1996 14:27:01 -0700 (PDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id PAA08439; Thu, 29 Aug 1996 15:26:42 -0600 (MDT) Date: Thu, 29 Aug 1996 15:26:42 -0600 (MDT) Message-Id: <199608292126.PAA08439@rocky.mt.sri.com> From: Nate Williams To: Brandon Gillespie Cc: hackers@freebsd.org Subject: Re: 'Backwards' DES support for crypt(), while still using better , algo's In-Reply-To: References: <199608291906.NAA07417@rocky.mt.sri.com> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > Sorry, I was not very clear :) What I'm suggesting is something different > > > from the secure distribution which gives you 'DES capability' while still > > > also having the capability of different encryption algorythms. It would > > > do this with a DES version '$0$' which would hook the encryption into DES > > > encrypt, where '$1$' would still hook into MD5 and '$2$' would hook into > > > SHA-1 (my code for crypt hooks into MD5/SHA-1 already, based off which > > > version you pass it in the salt), and not placing a version in the salt > > > would hook into the 'default' that crypt is using. This leaves it up to > > > crypt() to handle the default version, when newer and better algorythms > > > are added--without having to change passwd and all other relevant > > > programs. > > > > Except that this new password file is now FreeBSD-centric, and can't be > > shared with any other system. Simply adding a new 'token' for the SHA-1 > > stuff would be fine, but by changing what DES looks like is asking for > > trouble. > > The password file is already FreeBSD-centric, you cannot drop back to a > DES only (or Version 7) file with MD5/SHA passwords scattered through > it. This is a non-standard case. Most folks have all of one or the other. And, if you've got DES only passwords, you don't want them 'changed' to have a token in them. Special casing this is as much work as special casing 'not' having the token there, so you aren't buying anything but more work since all of the routines would have to see if it was a 'DES-only' password file and NOT prepend the token if so, else you can prepend the token. The current behavior of no-token == DES allows everything to work normally. Nate