Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!mcsun!ukc!strath-cs!baird!jim From: jim@cs.strath.ac.uk (Jim Reid) Newsgroups: comp.unix.questions Subject: Re: Security for UNIX ... looking for crypt() ... Message-ID: Date: 13 Jun 90 10:41:58 GMT References: <1139@neon.UUCP> <56@raysnec.UUCP> <13087@smoke.BRL.MIL> Sender: jim@cs.strath.ac.uk Organization: Computer Science Dept., Strathclyde Univ., Glasgow, Scotland. Lines: 30 In-reply-to: bai@iesd.auc.dk's message of 12 Jun 90 17:56:22 GMT In article bai@iesd.auc.dk (Bo Nygaard Bai) writes: In article <13087@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: >The export control concerns are solely due to legal considerations >and government bureaucracy, not because anyone is seriously worried >about crypt() "falling into the wrong hands". Don't forget protectionism. This is, as i see it, the only possible reason. Rubbish. What Doug Gwyn says above is absolutely right. Software to implement DES has been openly published and the DES specification will be available from any decent reference library. What could possibly be protectionist about something that is so freely available? DES is anything but a trade or military secret. What is an algorithm with export restrictions doing in UNIX ? Crypt(1) and crypt(3) have been around in UNIX for far longer than the US export regulations on encryption software. The crypt() routine continues to be exported by US vendors since it is used for login authentication rather than encryption. Secure NFS, mail etc. uses some form of the DES algorithm. When a SUN workstation leaves the US it has no des(1) or crypt(1), and no DES chip. This makes it virtually impossible to use secure NFS. This is no bad thing considering how insecure "secure" NFS is. Jim