From owner-freebsd-current Mon Jun 19 23:14:04 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id XAA27677 for current-outgoing; Mon, 19 Jun 1995 23:14:04 -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 XAA27657 for ; Mon, 19 Jun 1995 23:13:50 -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 IAA00709; Tue, 20 Jun 1995 08:13:36 +0200 Received: from localhost (localhost [127.0.0.1]) by grumble.grondar.za (8.6.11/8.6.9) with SMTP id IAA01182; Tue, 20 Jun 1995 08:13:34 +0200 Message-Id: <199506200613.IAA01182@grumble.grondar.za> X-Authentication-Warning: grumble.grondar.za: Host localhost didn't use HELO protocol To: terry@cs.weber.edu (Terry Lambert) cc: wollman@halloran-eldar.lcs.mit.edu, current@freebsd.org Subject: Re: Crypto code - an architectural proposal. Date: Tue, 20 Jun 1995 08:13:34 +0200 From: Mark Murray Sender: current-owner@freebsd.org Precedence: bulk > > 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. AHA! This makes sense. (sorta!) > It seems that the changes you want to make will result in someone having > to get the API recertified as exportable. True. I won't do it then. > The net effect of this is that CDROM distributions will become *more* > difficult to crypto-enable than they currently are. Right. I'll stick with what we currently have (more-or-less). Is there any reason that libcipher cannot be merged with libdes? > > > 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(). Thanks! Are there any other (potential) reasons why crypt(3) should be slow? M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200