From owner-freebsd-current Mon Jun 19 08:57:15 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA25281 for current-outgoing; Mon, 19 Jun 1995 08:57:15 -0700 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id IAA25206 for ; Mon, 19 Jun 1995 08:56:57 -0700 Received: from grumble.grondar.za (grumble.grondar.za [196.7.18.130]) by grunt.grondar.za (8.6.11/8.6.9) with ESMTP id RAA29724; Mon, 19 Jun 1995 17:56:44 +0200 Received: from localhost (localhost [127.0.0.1]) by grumble.grondar.za (8.6.11/8.6.9) with SMTP id RAA29080; Mon, 19 Jun 1995 17:56:43 +0200 Message-Id: <199506191556.RAA29080@grumble.grondar.za> X-Authentication-Warning: grumble.grondar.za: Host localhost didn't use HELO protocol To: Garrett Wollman cc: current@freebsd.org Subject: Re: Crypto code - an architectural proposal. Date: Mon, 19 Jun 1995 17:56:42 +0200 From: Mark Murray Sender: current-owner@freebsd.org Precedence: bulk > < said: > > > Included in the new DES code that I have (and in the old BTW) is > > fcrypt.c, which is a faster (2-3 times) replacement for the DES-based > > crypt(3) we are currently using. I would like to include this fcrypt.c > > in libdes to reduce the number of libraries produced. > > This is a bad idea for the following reason: > > 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. > 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. > Now, if you want to replace libcipher, go right ahead. I am actually having quite a hard time working out what the difference is between libdescrypt and libcipher. Could you enlighten me please? (I was of a mind to trash libcipher, as it seems superfluous.) M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200