Date: Tue, 20 Jun 1995 08:13:34 +0200 From: Mark Murray <mark@grondar.za> To: terry@cs.weber.edu (Terry Lambert) Cc: wollman@halloran-eldar.lcs.mit.edu, current@freebsd.org Subject: Re: Crypto code - an architectural proposal. Message-ID: <199506200613.IAA01182@grumble.grondar.za>
next in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506200613.IAA01182>