From: CSBVAX::MRGATE!hamm@biovax.rutgers.edu@SMTP 9-JAN-1988 23:20 To: ARISIA::EVERHART Subj: Cross-posting from FUTURE-L: Export restrictions on software (LONG) Received: from biovax.rutgers.edu by KL.SRI.COM with TCP; Sat 9 Jan 88 13:19:01-PST Date: 9 Jan 88 16:03:00 EST From: Subject: Cross-posting from FUTURE-L: Export restrictions on software (LONG) To: "info-vax" Reply-To: I found the following of sufficient general interest to re-post to INFO-VAX. My apologies if you've already seen it elsewhere. Although the article deals mainly with DES, I wonder how the regulations discussed would apply to the CMU TCP/IP implementation, and the SPICE software in the DECUS library, both of which are available to the "public" at nominal cost in this country, but claim (last I saw, anyway) to be under export restrictions. I'd be interested to hear any qualified opinions on this. Greg ------------------------------------------------------------------------------ Gregory H. Hamm || Phone: (201)932-4864 Director, Molecular Biology Computing Lab || Waksman Institute/CABM || BITNET: hamm@biovax P.O. Box 759, Rutgers University || ARPA: hamm@biovax.rutgers.edu Piscataway, NJ 08854 * USA || ------------------------------------------------------------------------------ Date: Fri, 8 Jan 88 21:43:42 -0500 Reply-To: BITNIC FUTURE-L List Sender: BITNIC FUTURE-L List From: Rayan Zachariassen Subject: Re: DES To: "GREG H. HAMM" In-Reply-To: <8801090124.AA07651@gpu.utcs.toronto.edu> After you read the following article (referred to earlier by Dennis Ferguson), hopefully the DES discussion will disappear from this list. Date: Mon, 26 Oct 87 17:18:36 PST From: John Gilmore Message-Id: <8710270118.AA09965@hop.toad.com> Subject: Export control does *NOT* apply to publicly available software. Newsgroups: comp.society.futures To: info-futures@bu-cs.bu.edu References: <8710222017.AA01466@hadron.UUCP> <276@ddsw1.UUCP> I researched this topic pretty thoroughly last year, by going down to the local Federal Building and wading through the rulebooks in Commerce Dept. library. What prompted me to do it was that I had a PD DES, that I had posted to comp.sources.unix, which a Canadian reader claimed was in violation of export laws. Rich $alz took the info I got and talked with the NSA (US National Security Agency) and some Boston-area cryptographers. The upshot was that NSA never came up with anything that contradicted the rules I found, and Rich posted not only the DES code, for worldwide distribution, but also the "crypt breaker's workbench" that decrypts the ancient Unix "crypt" command. Now, the way things wag with NSA is that if you ask them "Can I do this?" the answer is almost always "No". What you have to say is "Show me the rules that say I can't do this. I have some that say I can." The courts have regularly ruled that the government cannot enforce a policy which is not written down and equally applied to everyone (it's called "secret law"). So if what *is* written down supports you, they are stuck with it. They can't secretly make new laws and tell you later that you broke them. Since everyone else on this topic is shooting off their mouth without having done any research (now we have *two* Canadians who are falsely telling us what the US export law is -- thanks guys!), I figured I'd better post my full references to make it credible. Save this message; if I ever leave the net somebody had better have a copy to shout down the clowns again. From: gnu@hoptoad.uucp (John Gilmore) Newsgroups: net.crypt,net.sources.d,net.legal Subject: There are basically no export controls on public domain information. Message-ID: <1176@hoptoad.uucp> Date: 3 Oct 86 23:57:06 GMT I got into a hassle last month for posting a DES program to mod.sources because someone claimed that I was breaking the export control law. I spent the afternoon down at the Federal Building and discovered that export policy is in better shape than I thought. Basically, you can export any technical data to any destination if it "has been made generally available to the public in any form". This export is under a "general license" which is available to everyone without any paperwork. So, you should expect to see the DES posting again (it was canceled) and to see Crypt Breaker's Workbench on mod.sources soon. Here are the regs for all you policy hounds: Export Administration Regulations, Part 370.2, Definitions. "General License. A license established by the US Department of Commerce for which no application is required and for which no document is granted or issued. It is available for use by all persons, except those listed in and prohibited by the provisions of Supplement No. 1 to Part 388, and permits export within the provisions thereof as prescribed in the Export Administration Regulations. These general licenses are not applicable to exports under the licensing jurisdiction of agencies other than the Department of Commerce." Part 379.1, Definitions. "... All software is technical data." Part 379.2, Licenses to Export. "Except as provided in Part 370.3(a), an export of technical data must be made under either a US Department of Commerce general license or a validated export license. General licenses GTDA and GTDR apply to specific types of exports of technical data..." Part 379.3, General license GTDA: Technical Data Available to all Destinations. "A General License designated GTDA is hereby established authorizing the export to all destinations of technical data described in 379.3(a), (b), or (c) below: (a) Data Generally Available Data that have been made generally available to the public in any form, including-- (1) Data released orally or visually at open conferences, lectures, trade shows, or other media open to the public; and (2) Publications that may be purchased without restrictions at a nominal cost, or obtained without costs, or are readily available at libraries open to the public. The term "nominal cost" as used in 379.3(a)(2) above, is intended to reflect realistically only the cost of preparing and distributing the publication and not the intrinsic value of the technical data. If the cost is such as to prevent the technical data from being generally available to the public, General License GTDA would not be applicable. (b) Scientific or Educational Data ... (c) Patent Applications ..." ------ (end of first message) John here, talking to info-futures again. Chris Lewis (the first Canadian "expert") tried to pick the above to pieces, so I provided more explanation by private mail, now revealed to the info-futures readership for the first time ever! Date: Sun, 12 Oct 86 16:57:06 PDT From: gnu (John Gilmore) Subject: Re: Export control revisited Chris Lewis is still somewhat concerned about export control. I will try to explain the things he mentioned in his message of 8 October. >> "General License. A license established by the US Department >> of Commerce for which no application is required and for which >> no document is granted or issued. It is available for use by >> all persons, except those listed in and prohibited by the >> provisions of Supplement No. 1 to Part 388, and permits export > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > what is this section about? It lists people who have abused the general license in circumstances where it does not apply (eg shipping Vaxen to Russia). The idea is that you are innocent until proven guilty with regards to general licenses. I looked in the supplement and it was a 3-page list of names and cities. I was not on it. :-) >> within the provisions thereof as prescribed in the Export >> Administration Regulations. These general licenses are not >> applicable to exports under the licensing jurisdiction of agencies >> other than the Department of Commerce." > ^^^^^ ^^^^^^^^^^^^^^^^^^^^^^ > DOC is not the only agency involved. I also got myself a copy of the regulations on cryptographic material export, but I didn't include it in my posting since it did not apply. It's listed under Part 399.1, supplement #1 (the Commodity Control List), "ECCN 1527A". It mentions that computers when combined with cryptographic software are covered under this ECCN, and says "Technical Note: No technical data or software controlled under this ECCN may be exported or reexported under General License GTDR." HOWEVER, we are exporting under General License GTDA, not GTDR, and this is a valid distinction. There is nothing in this ECCN section that precludes shipping cryptographic technical data (e.g. software) under general license GTDA. It also says, "Exporters requesting a VALIDATED LICENSE from the Department of Commerce must provide a statement from the Department of State, Office of Munitions Control, verifying that the equipment intended for export is under the licensing jurisdiction of the Department of Commerce." (emphasis mine) However, we are not requesting a validated license, we are using the general license, so this requirement does not apply either. In summary, I believe that the provisions of ECCN 1527A do not apply to public domain software, and we are OK. (I don't know of any other ECCN sections that apply either.) >> Part 379.3, General license GTDA: Technical Data Available to all >> Destinations. >> "A General License designated GTDA is hereby established >> authorizing the export to all destinations of technical data >> .... >> >> (1) Data released orally or visually at open conferences, >> lectures, trade shows, or other media open to the public; and >> >> (2) Publications that may be purchased without restrictions >> at a nominal cost, or obtained without costs, or are readily >> available at libraries open to the public. > >This, in turn: > > 1) Has *this* DES program been formally published before? > 2) Can it legally be? Journals are supposed to be reviewed prior > to publication by one of the security agencies. We're a loophole. > 3) From another tack: can you make a DES program PD? (1) You elided the relevent section of the general license definition. "(a) Data Generally Available: Data the have been made generally available to the public IN ANY FORM, including... (1) and (2)...". (emphasis mine.) If something has been placed into the public domain and its location advertised to the Usenet community, or placed into a publicly accessible bulletin board, or posted to the Usenet, I claim that it has been made generally available to the public. (1) and (2) are not the only ways something can be made available to the public; they are just examples. (2) You can't be expected to know how things work in the U.S., being Canadian, but there is NO requirement that "journals are supposed to be reviewed prior to publication". We have a free press here. They tried to impose something like this and it didn't work. There is a "voluntary" system whereby authors can submit manuscripts to the NSA for review, but you are not even bound by the result -- they can only make suggestions. Mostly this is so they can recommend that you delete certain phrases that might give away what they are working on, and you are supposed to feel patriotic enough to go along. Presumably they could also try to go to court to stop you from publishing, but I don't think that has happened to any paper that has been voluntarily submitted under this program. (They did go to court against the magazine that published the "how to build an atom bomb" article.) You may be confused between mandatory review of journals and the Defense Department's right to review articles by people who they fund. If you are doing government-sponsored research, they can write the contract such that they get to OK any release of information derived from the sponsored research. But if I invent something on my own, without gov't money, I can publish it. (3) Public Domain-ness is a state of ownership. Since you can certainly own a DES program (e.g. AMD owns the copyright of the 8068 DES chip; ATT owns crypt(1)), you can also renounce its ownership and place it into the public domain. >You didn't include anything from 370.3 (or is that a typo?) either. It was not a typo. I don't have a copy of it here, but I don't think it applies to us. It's part of the "General Policy on Exports" section. >If this program were to be published in a technical magazine (presumably >safest in a real journal, not necessarily BYTE), then I'd feel safe >because they've already had approval. BYTE published one or two DES programs >ages ago, but this was before the NBS standard was formalized. Presumably >you could publish *that* program (6502 assembler), but not anything written >since then. I haven't seen a DES program since (though, I don't read all >that many journals...) This objection is covered above -- there is no required government review of publications here, and no government approval is required to publish. >I realize perfectly well that a court challenge on this would probably >find in our favor - as in, is DES in software really DES? But, I want >to ensure that we stay well clear of the shadow (if not the substance) >of the law. Actually, this is not relevant. The export control regs don't mention DES at all. They say "cryptographic equipment...designed to ensure secrecy of communications...or of stored information...and "software"... performing the functions of such cryptographic equipment", and then make a few exemptions for things like simple scrambled voice, video, or fax. >I can't help remembering the export restrictions on crypt (which, I believe >are still in effect *even tho* Enigma has been declassified for years), >AT&T's security package, Motorola and Intel's encryption boards etc. >I remember seeing discussions in trade journals 2-4 years ago about DES >export restrictions, code-breaking discussions, other more recent encryption >methods, but I can't remember where. None of the above stuff is "technical data generally available to the public", so it cannot be exported under the GTDA general license. Note that journal articles like the AT&T Tech Journal one on breaking crypt are generally available to the public, and they are being exported without trouble. Ditto for _Cryptologia_. It *DOES* take an export license to export non-public technical data, e.g. the Unix crypt command (licensed software), encryption boards (hardware, not technical data), etc. I must say that I felt the same way you do about this -- I had a general feeling that exporting this stuff was illegal, even though I thought it should be legal -- until I spent the time to research it. My opinion of the people who wrote US export law has gone up significantly. They really believe that if the US "public" can get it, it is exportable. FYI, here is the definitive story on how the "export restrictions on crypt" came about, from Dennis Ritchie himself. As you can see, no government agency ever said it could not be exported; AT&T and DEC simply decided that applying for an export license was too much trouble. I've also included a message from Gordon Moffett who says that Amdahl is now exporting Unix with the crypt command without trouble. >From dmr@research.UUCP Mon Sep 17 22:15:46 1984 Path: CSL-Vax!decwrl!decvax!mcnc!unc!ulysses!allegra!alice!research!dmr From: dmr@research.UUCP Newsgroups: net.crypt Subject: export controls Message-ID: <1041@research.UUCP> Date: 18 Sep 84 05:15:46 GMT Posted: Mon Sep 17 22:15:46 1984 As has been said, there is indeed a special "International Edition" of System V that differs from the ordinary system in that it lacks the crypt command, the encrypting features of ed and vi, and the encrypt entry of crypt (3). The crypt entry, which is used for passwords, is there, as is the underlying DES algorithm. Here's how it happened. About a year ago, I got mail from Armando Stettner saying basically, "Do you know of any problems with exporting crypt? Our lawyers [at DEC] are worried about it." I replied that such worries were utterly unfounded for a variety of sensible reasons. Now, as it has turned out, DEC was very justified in worrying about export controls in general; they have recently been fined (I think) $500,000 for the Vaxen that almost got sent to Russia. I conjecture that the earliest stages of this or a similar incident were already in progress and they were trying to be extra careful when they learned about crypt. At any rate, the DEC lawyers communicated their fears to AT&T, and the AT&T lawyers, equally cautious, sought government advice. The problem, you see, is that cryptographic materials are under export control. There is a thing called the Munitions Control Board that worries not only about machine guns going to Libya, but also about the crypt command going to England. In practice, the enforcement is done by the Commerce department. AT&T had a meeting with Commerce, the MCB, and NSA. The upshot was that they decided it would be simplest all around just not to export the crypt command. The gov't would almost certainly have granted the license, but (probably wisely) AT&T decided it wasn't worth the hassle. In technical terms, the situation is ludicrous. The encrypt subroutine is distinguished mainly by the excruciating care I took to make it an exact transcription of the algorithm published in the Federal Register, and by its slowness. NBS, the caretaker of DES standardization, is explicit that software implementations cannot be certified, so in that sense encrypt is not "real" DES. The underlying subroutine is still there, only the simple command that uses it is missing. So there is actually nothing to protect, and even if there were, it's not protected. Nevertheless, in the present situation we officially don't need an export license, whereas with the crypt command we would. In political terms, AT&T probably could have done better. Conservative and careful, they called a big meeting at which no one could possibly have put forward anything but official positions about encryption programs. Private checking with well-placed people in the appropriate agencies might well have done the job. But who knows? Dennis Ritchie ----- In article <3140@amdahl.UUCP> Gordon Moffett writes: Our Corporate legal advisor says that the restrictions against exporting encryption stuff has been lifted. We used to have two UTS's: one with the crypt(3) stuff for domestic customers, and one without export. We no longer distiguish between the two -- we now ship everything to non-USA customers just as to the USA sites. I've already gotten one letter about this, asking me for further confirmation that this is ``true''. First, PLEASE DON'T ASK ME! Talk to *your* companies' legal advisors, or to the Federal Government directly. Second, I am sure we would hear about it from the Federalees if our Corporation were making a mistake .... -- Gordon A. Moffett ...!{ihnp4,seismo,hplabs}!amdahl!gam [Back to Chris's comments: -- gnu] >The definitive answer would be to see whether the current listing of >restricted items includes DES, and in what forms. I don't think excerpts >from a different set of legislation is sufficient to answer this question. >Further, there *may* be a difference between "legislation" and "regulation" >here. DES restriction might *not* be enshrined in legislation, but come >out of some other department's regulatory powers. The second paragraph >I've quoted still leaves that whole question open. I have spent the time researching it, and I think it's OK to export. If you still think differently, please give details of the regulations or laws involved. I'm not interested in "maybes"; I have an answer that came straight from the rule books, and won't be swayed from it by anything less definitive. ------