From owner-freebsd-hackers Sun Jun 4 05:37:30 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id FAA09469 for hackers-outgoing; Sun, 4 Jun 1995 05:37:30 -0700 Received: from bunyip.cc.uq.oz.au (bunyip.cc.uq.oz.au [130.102.2.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id FAA09463 for ; Sun, 4 Jun 1995 05:37:27 -0700 Received: from cc.uq.oz.au by bunyip.cc.uq.oz.au id <14713-0@bunyip.cc.uq.oz.au>; Sun, 4 Jun 1995 22:36:26 +1000 Received: from saturn.mincom.oz.au by minbne.mincom.oz.au with SMTP id AA04121 (5.65c/IDA-1.4.4 for mark@grondar.za); Sun, 4 Jun 1995 22:33:46 +1000 Received: by saturn.mincom.oz.au id AA20766 (5.65c/IDA-1.4.4 for hackers@freebsd.org); Sun, 4 Jun 1995 22:35:40 +1000 Date: Sun, 4 Jun 1995 22:35:40 +1000 (EST) From: Eric Young To: Mark Murray Cc: Tim Hudson , Eric Young , hackers@freebsd.org Subject: Re: DES, eBones and crypt availble for non-US! In-Reply-To: <199506040954.LAA12533@grumble.grondar.za> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: hackers-owner@freebsd.org Precedence: bulk On Sun, 4 Jun 1995, Mark Murray wrote: > 1) I am trying to find pointers to the official legal status of crypto > code in various countries. I know that the USA/Canada considers this > to be a munition, so exporting it illegally is like gun running. > I heard a rumour that Australia was the same. I also heard something > about this code being illegal for possession in France. Any comments/ > pointers? As far as I know, the USA/CAnada is as you suspect. Australia, I don't know about, so make sure you take a copy of my code before they take me away :-) (Actually I have had my DES library up for so long, I think things would be very strange if they acted now :-). I have heard that it is illegal to import encryption stuff into France. I am working on a file to go with my SSL distribution that says what I think the postion is. The best part is that it appears that it may be ilegal for USA people to use my RSA code, a bit of a change :-) > 2) We are all treating eBones with respect and not getting it from the > states, but is contains no crypto code, only calls. Is it or is it not > legal for export? I need a definitive answer here. (I vaguely remember > something about a `sanitised' Kerberos/eBones (or is this eBones > itself?). Ah some history :-) What happended many many moons ago when I was fresh out of Uni ('89), I got a job as a postgraduate fellow at the newly started Bond University on the Gold Coast in sunny old Queensland. This position ment I was doing a PhD part time and working as a systems programmer part time for the Computing School. After about 9 months of me doing absolutly nothing on the PhD I just swapped over to being the Schools full time systems programmer :-). Part of their setup of the Computing School was to set up a workstation environment similar to that at MIT. People came out from MIT to do this setup. They left after some time and I was left with what was left behind :-(. Kerberos as we know cannot be exported, but they did install a version called Bones. Bones was what was left after a program called Parania (sp?) was run over kerberos which removed all the cryptographic calls. 'They' were not even alowed to leave the cryto call in the library, they had to all be taken out. It fell upon me to put encryption back in. This was not much fun at the time (I found the kerberos code a little ugly to understand, probably because I was just fresh out of Uni :-). Out of this came eBones (encrypting Bones) and my libdes DES library. When I left Bond Uni for a job at the Psych department at the University of Queensland, I left behind any work I was/had been doing on eBones since the environment was unsuited to Kerberos. I did continue working on the DES library, and had a bit of contact with eBones when some other Department wanted to talk to Terminal Servers. Otherwise I though I had escaped my resposibilities :-) > The code we have includes a Kerberised telnet, in a non-functional state (I > think someone in the US has fixed this, but he obviously can't let us > get it). Do you have a working one? Unfortunatly no. I'm quite willing to help support SSL telnet though :-). The rlogin that came with eBones was a bit ugly and I seem to remember out of band data did nasty things to it when I left it. > How long before an official release? Well it is sort of officially released. The documenting and improving of the library interface will continue for some time but the full functionality is there. As I put it on my mailing to the ssl-list, I had missed 2 self imposed deadlines, it worked, and if I held of until things were perfect, it would never get released :-). I'm only telling a few mailing lists so that I can make sure the bugs are fixed and our documentation is good enough so that I don't get inundated with email when the unwashed masses are told about it :-). When it gets anounced on sci.crypt etc, it should be interesting, considering SSLref costs $30k for a commercial licence and RSAref costs $10k. Mine is free. SSLref actually uses RSAref and my DES library (it can use other DES libraries as well). Mine contains everything in one build tree. I have written this on my own time more as therapy for myself (nothing like mindless obsessive programming for a month or 2 to get your mind off other things :-) but I will be interested to see what kind of 'political' fuss this causes, especially in the USA with the software patent issues. Worst case for people in the USA appears to be RSA refusing to 'licence' my version od the RSA algorithm, so people in the USA will have to pay RSA a licence fee while people out side the USA will have a free version available for comercial use. The people writting www servers/clients will have an interesting time. I'm more in this for doing SSL telnet/telnetd. But anyway, I digress, take it, have a play but I would sugest not doing too much with the code yet since I'm still changing it quite a bit. Do send me sugestions though. > Would we be able to hack this code into our source tree? We have our own > make system, and we would gladly preserve any attribution. (I have read > the next paragraph, but I am now asking if we may 'BSD-ise' this. It may > then divert a bit from your mainstream development. (Not much if what I > have seen so far of the BSD team is anything to go by) I'm very keen to keep control of the 'direction' of this library. I will gladly put your changes into my distribution. Even if it comes down to taking my distribution, unpackit, run FreeBSDit and then it's in your tree. If the Makefile names are not Makefile (or makefile) I'd also just plop them into my trees. Please remember this is a library, it produces libssl.a libcrypto.a and libdes.a, which are installed in the area specified in the makefile. Hopefully, when I'm finished, there should be no need to make any changes for any platform except to change the makefiles (and a few defines for performance reasons). It is still currently changing quite a bit and so if you do want to 'branch off' another development tree, definitly hold off until it is more stable (not that it does not work, it's just that there are about 200 function (mostly X509/rsa) which are mostly undocumented, and I add more as I need them to make the library easier to use :-). eric