From owner-freebsd-current Mon Jun 19 22:49:09 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA25570 for current-outgoing; Mon, 19 Jun 1995 22:49:09 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id WAA25560 for ; Mon, 19 Jun 1995 22:49:06 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA24561; Mon, 19 Jun 95 23:41:51 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9506200541.AA24561@cs.weber.edu> Subject: Re: Crypto code - an architectural proposal. To: mark@grondar.za (Mark Murray) Date: Mon, 19 Jun 95 23:41:50 MDT Cc: wollman@halloran-eldar.lcs.mit.edu, current@freebsd.org In-Reply-To: <199506191556.RAA29080@grumble.grondar.za> from "Mark Murray" at Jun 19, 95 05:56:42 pm X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@freebsd.org Precedence: bulk > > The current libdescrypt.so was designed specifically to ensure that it > > would be easy to get an export license for the binary. This is done > > by having the library only export one entry point, the UNIX one-way > > hash function crypt(). I don't want to see this broken. > > I don't quite understand. The code I have has no restrictions apart from > the US crypto export one. What I am proposing to do is include it with a > library that has exactly the same restrictions. I want to do this to > reduce the number of libraries, seeing that some of what I am doing may > increase that number. The problem is that the API has been designed to meet US export code restrictions such that a non-crypto exported system can be easily turned into a crypto-enabled system external to the US without a lot of work. It seems that the changes you want to make will result in someone having to get the API recertified as exportable. The net effect of this is that CDROM distributions will become *more* difficult to crypto-enable than they currently are. > > There are also some reasons for wishing that the system crypt() were > > slower as opposed to faster than it is now. > > What are they, please? If it is to slow down hack-attacks, then this is > not really a reason, as a hacker could either bring his own fast crypt(3), > or we could slow down login(1) etc with sleep(3), giving us the advantage > with the crack programs. I agree that the hack-attack prevention is a poor reason for slowing down crypt(). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.