by Marc Plumb
First written May 21, 1996
Last modified June 25, 1996
- There are a few countries to which you may not export anything, without a permit.
- You need a permit to export most cryptographic software.
- It is legal to export Canadian software, even cryptographic software, which has no restrictions on distribution (public domain software). This must be explicitly stated, not just implied by being available for public FTP. No paperwork needs to be filled out.
- Public domain cryptographic software of U.S. origin may be exported, but you still need to file paperwork.
- Public domain cryptographic software from other countries may be exported without any paperwork.
- These are the Canadian rules. How the U.S. laws apply, and how they are enforced is not clear. The U.S. government has charged people for exporting goods from Canada.
What I Asked to Export
Applicable Export Controls
In September 1995, I started investigating the export controls in the U.S. and Canada. When I got a copy of Canada's Export Control laws, I was pleasantly surprised. I had previously looked at the U.S. regulations and found them to be very confusing. Reading over the Canadian laws I determined that strong cryptographic software is exportable, under some conditions. The persecution of Phil Zimmermann in the U.S. Made me nervous enough that, I decided to take the cautious approach and file a set of export permit applications, so that I could be sure that I was correctly interpreting the regulations. This is an explanation of what I have learned.
I asked for, and received, notice that I do not need permission to export: Canadian DES code (similar to this), Kerberos, SFS, Peter Gutmann's cryptographic library, and the MPQS factoring package.
Most of the following quotes are from "A Guide to Canada's Export Controls, April 1994". The forward does a good job of explaining the laws and procedures, and the regulations themselves are surprisingly readable, particularly when compared with the U.S. International Traffic in Arms Regulations (ITAR). I have been told that the booklet is used internationally as a rough guide to export law. Many countries share approximately the same export restrictions, and the Canadian regulations are particularly easy to understand. The 1996 Guide will be out in a few weeks, and it should be available electronically by the autumn of 1996.
Permits are required for all exports to countries on the Area Control List (ACL). You may not even export a pencil to a country on the ACL, without a permit. To the best of my knowledge, as of April 1996, the ACL includes only Angola, and Libya. (This has changed at least twice in the last eight months, so check the ACL again before you export anything.) Most exports to Iraq are also prohibited, due to a U.N. embargo.
Since information could be considered an export controlled good, an overly broad interpretation of the ACL would make it illegal to phone, let alone send e-mail to some countries. This is ridiculous, so I am not going to worry about it too much. It is a problem that would affect all Internet, telephone, and other communications equally, not just cryptographic software.
The Export Control List (ECL) specifies goods which require a permit to export. Section 1150 of the ECL, controls the export of goods and technologies dealing with Information Security. Anything that deals with cryptography, cryptanalysis, or detecting bugs is controlled. There are exemptions for some faxes, TVs, cellular phones, simple voice scramblers, and anti-piracy measures for software. Software is controlled, as is technology, such as plans, technical data, or instructions.
Item 1000 in the ECL is a General Technology Note (GTN) and a General Software Note (GSN). These notes permit the export of "software" or "technology" that is "in the public domain", and also permit the export of "basic scientific research".
The General Software Note allows the export of "software" which is designed for installation by the user alone, without further substantial support by the supplier. It also includes "software" which is sold from retail selling points by mail order, telephone, or over-the-counter transactions. I have not tested this, but I think this means that as long as you make your commercial software easy to use and readily available, there are no export controls. (Perhaps someone with commercial cryptographic software to sell can try to get an official confirmation of my interpretation.)
At this point, some definitions would be useful. The definition section alone makes the ECL much easier to read than the ITAR. Anything in quotes in the ECL has a definition. (Except "microprogramme", which got left of the 1994 guide.)
Copyright restrictions do not remove "technology" or "software" from being "in the public domain".
The exact definition of "in the public domain" was a sticking point on my permit applications. I was told that software must explicitly be freed of any restrictions on distribution; it is not sufficient to imply that software is "in the public domain" by just putting it up for anonymous FTP.
I take this to mean that PGP sent over the Internet might not be "software", but "technology". It is possible to feel the tangible communication cables, but the data are not fixed at the time of export.
So, "programme" includes source code, and executable.
(As defined in the 1996 guide)
1. "Technical data" may take forms such as blueprints, plans, diagrams, models, formulae, tables, engineering designs and specifications, manuals and instructions written or recorded on other media or devices such as disk, tape, read-only memories.
2. "Technical assistance" may take forms such as instruction, skills, training, working knowledge, consulting services. "Technical assistance" may involve transfer of "technical data".
"Technology" is a bit of a catch all category, so I think that is where Internet communications fall. It is also interesting to note that telling someone how to use PGP may be a form of "technology" and may therefor be export controlled. Public domain "technology" is not embargoed, so freely distribute your advice. Since Export Controls wanted an explicit statement allowing free distribution of software, a similar statement might be required for "technology". (Yet another silly disclaimer to add to your postings.)
So far I have only really discussed Canadian cryptographic software. Item 5400 of the ECL, restricts the export of U.S. goods. Item 5400 controls the export of all goods that originate in the United States, unless they are included elsewhere in the ECL, or have been further processed outside the U.S. This further processing must result in a substantial change in value. The Canadian DES code had 15% U.S. content. My conversations with people at Foreign Affairs indicate that if more than 50% of the actual value of a good (don't include mark-up) is due to work outside the U.S., then the good is not considered to be of U.S. origin. This may change in the future, since exactly where this line is drawn is a topic of debate between Canada and the U.S.; the U.S. wants to be able to exert control over as much as possible.
Export Controls decided that the General Technology Note does not apply to U.S. goods. It only applies to items in Group 1 of the ECL, i.e. those items starting with a "1". However they did tell me that something called General Export Permit number Ex. 12 does apply.
The General Export Permit (GEP) was introduced to make it easier to export less sensitive goods. A GEP is a valid export permit, just as if you had applied for, and received, an Individual Export Permit. Any Canadian resident may use a GEP without any prior approval, but you must ensure that the goods to be shipped qualify for the GEP and that the conditions for use of the GEP are fulfilled.
(b) Democratic Peoples Republic of Korea;
(c) Iran; and
(d) Viet Nam.
SInce the U.S. is now trading with Vietnam, that part of GEP 12 is not enforced. I do not have this in writing, but it was publicly stated at the May 30, 1996 Export Controls Seminar in Toronto. I assume that Vietnam will eventually be removed from GEP 12.
To export U.S. crypto code, you need to file two copies of Canada Customs' Form B 13A. (Mark the second one "Duplicate" to avoid confusing Canada Customs. These forms are available from any customs office, and are supposed to be submitted at the point of exit, which is the post office, if you are mailing it. When I tried this, the clerk just looked at me strangely. Canada Customs tells me that they will try and clear up this confusion, so try and submit the form at the post office. I just got the post office to date stamp the forms, and then mailed them to:
Customs Border Services
Export Controls Unit
Lester B. Pearson International Airport
P.O. Box 40
Toronto AMF, Ont.
If you are carrying the software, then submit the forms at the border.
If you want to send crypto software over the Internet, you might be allowed to do it without any paperwork. I was told, by Keith Watkins of Revenue Canada Customs and Excise, that Canada Customs does not have the authority to regulate Internet communications. This seems strange to me, and other people at Canada Customs told me to file the paperwork before making the export. I think that it would be nice to file the paperwork even if it is not needed, mainly to tell Statistics Canada about your exports so they can know how important the Internet is.
Note: Even if Canada Customs cannot control Internet transmissions, you can still get arrested for sending, or receiving, some types of data -- threatening, obscene, etc.
When filling out the B 13A form, you need an Exporter Account Number, or a Business Number. If you are only going to do one or two small exports then you do not need one, just write in something like "Only one export, no number needed". If you plan on doing more, you should get a number. I am not sure how to go about getting a Business Number. I have been referred to Form RC1(E) "Request for a Business Number", Form T 124 "Request for Importer/Exporter Account Number", and "Business Registration Number Kit, for new registrants". Apparently all of these are available from any Customs office. There is no need to wait for your Business Number, you may just write in "Business Number applied for" on the form.
You also need to fill in an HS Commodity Code. There is not yet a Harmonized System code for software. Instead consider a disk containing software to be two items. For a 3.5 inch floppy disk, the HS code is 8524.53.00. For the software portion, just write in "No HS code exists", but be sure to fill in a description of the software.
There are methods, which can be arranged, that let you file after the export, if you do a lot of exporting. For more details about any of this get a copy of Revenue Canada Memorandum D20-1-1. Be advised that getting permission to do this summary declaration is very difficult.
Item 5401 of the ECL may restrict the export of goods from other countries, but I have been told that no export permit, of any sort, is required for public domain cryptographic software.
I received some misinformation about this which made it into the first version of this document.
This is a difficult and confusing issue. Canada and the U.S. have a very close trading agreement. With a few exceptions, no export permits are needed to ship goods between Canada and the U.S. Even controlled U.S. goods are much easier to export to Canada. Section 126.5 of the ITAR allows U.S. citizens to export controlled goods to Canada without a permit -- they just need to fill out a Shipper's Export Declaration.
The openness of trade between Canada and The U.S. is useful arrangement, so both Canada and the U.S. would like it to continue, but it is also an uncomfortable arrangement because the U.S. government still wants a say about where U.S. goods are exported to from Canada. The balance seems to be that if Canada already controls a given U.S. origin good, then Canada considers the U.S. export laws before granting an export permit. If Canada does not control the export of a U.S. origin good, then the restrictions added by GEP 12 are usually sufficient to keep the U.S. happy. In the case of public domain crypto software, it is not controlled by Canadian law, so the U.S. laws were not considered by Export Controls. Even if the U.S. laws had been considered, that is no guarantee that the U.S. would agree with Canada's interpretation.
People exporting U.S. origin goods from Canada have occasionally been denied entry to the U.S. I have been told that In 1985 or 1986, a Canadian man named Kline was arrested when he entered the U.S. The trial was in Boston and a few people from Canada's Export Control division testified. Apparently the U.S. suspected that Kline was violating the terms of GEP 12 by exporting U.S. origin goods which were ultimately destined for a prohibited country. I was told that Kline had a Canadian export, and was eventually found not guilty, but I do not have any details. If anyone finds out more about this case, please let me know.
All of this makes me glad that I was paranoid enough not to actually export anything I got from the U.S.. I do not really think that I will get into any legal trouble if I go to the U.S. In general I have been told by people at Canada's Export Controls division that the U.S tends to get annoyed when they think that someone is going through Canada simply because they want to circumvent the U.S. restrictions. I was not exporting the software from Canada specifically to get around the U.S. restrictions, I did it to test the Canadian ones. It was also software that I was interested in and studied before exporting it, as well as the fact that I am in Canada, so I do not have much choice about bringing things through Canada.
This section may be useful for those who wish to export other controlled goods. There were a few parts of the application process that were vague. I hope that these examples will make life easier for someone else.
I asked for permission to export several pieces of cryptographic software, on floppy disk. I did not simply ask to export the software itself; Software is strangely defined in the ECL, so I thought it was safer to make the export on disk. The descriptions that I included were:
( 85% Canadian, 15% U.S. origin )
A software implementation of the Data Encryption
Standard, with C source code. Can also be used for
( 85% Canadian, 15% U.S. origin )
( 100% U.S. )
Documentation and C source code for Kerberos version 5,
beta 5. This is the fifth MIT beta-test release of the
Kerberos version 5 library and associated applications.
Kerberos is a well-known authentication and data
security system for inter-computer communication over
insecure networks using conventional (single-key)
cryptographic techniques. The central cryptographic
algorithms used are DES and MD5. Kerberos provides
facilities for secure and authenticated file transfer and
interactive connections between computers, providing
equivalents to the Unix rlogin, rcp, rsh and telnet
commands, a secure POP (post office protocol) electronic
mail transfer facility, and documentation and examples to
facilitate its integration with other applications.
( 100% U.S. )
( 100% U.S. )
C source code and installation documentation for MPQS-1.5,
the sieving component of a multiple polynomial quadratic
sieve implementation. This consists of a large integer math
library and a small application to carry out parts of the
sieving for MPQS factorization of large integers.
( 100% U.S. )
( 100% New Zealand )
Documentation and portable C source code for a software
encryption library by Peter Gutmann. The only cipher
provided by the library is MDC-SHA (Message Digest Cipher,
as described in Applied Cryptography, pp. 271-272, with
the NIST Secure Hash Algorithm FIPS 180, in cipher
feedback mode). The library is intended to be easily used
and extended. The library is not a complete program, and
must be incorporated into a larger application to be useful.
( 100% New Zealand )
This is an MS-DOS installable device driver that provides
transparent access to an encrypted hard drive partition or
floppy disk. Each disk sector is encrypted independently
using a 512-bit partition key chosen at installation time.
The partition key is stored in the boot sector of the
partition, encrypted with a user-selected password which may
be easily changed. The user password is converted to a
512-bit binary key for this encryption by combining it with
a random "salt" value, stored with the encrypted partition
key, and applying a cryptographic hash function iteratively
in a process that is designed to be unavoidably slow,
making brute-force password guessing difficult.
Each sector is encrypted in two passes. The first pass uses a
keyless "scrambling" operation (equivalent to the scrambler
polynomials widely used in telecommunications protocols)
using an initial vector that is a function of the sector
address within the partition and some random data that is
stored encrypted with the partition key. This scrambling
operation has the property that the last 160 bits of the
scrambled sector are a non-cryptographic hash of the entire
The second pass uses the NIST Secure Hash Algorithm
(FIPS 180, prior to the 180.1 revision) in cipher feedback
mode (CFB-160) as a message digest cipher (MDC, as described
in Applied Cryptography, pages 171-172), with the last 160
bits of the scrambled sector serving as the initial vector
for the encryption pass.
The software includes provisions for wiping plaintext and key
material from memory on user command, after a user-selectable
time delay (since a given partition was last accessed), or
with a single-key "hot key" command.
The software further includes provisions for securely erasing
a partition, using multiple overwrite passes designed to
minimize residual magnetic remanence, and for decrypting a
partition, returning it to service as an unencrypted device.
( 100% New Zealand )
Documentation and MS-DOS executable programs for Secure File
System (SFS) version 1.10.
This is an MS-DOS installable device driver that provides transparent access to an encrypted hard drive partition or floppy disk. Each disk sector is encrypted independently using a 512-bit partition key chosen at installation time. The partition key is stored in the boot sector of the partition, encrypted with a user-selected password which may be easily changed. The user password is converted to a 512-bit binary key for this encryption by combining it with a random "salt" value, stored with the encrypted partition key, and applying a cryptographic hash function iteratively in a process that is designed to be unavoidably slow, making brute-force password guessing difficult.
Each sector is encrypted in two passes. The first pass uses a keyless "scrambling" operation (equivalent to the scrambler polynomials widely used in telecommunications protocols) using an initial vector that is a function of the sector address within the partition and some random data that is stored encrypted with the partition key. This scrambling operation has the property that the last 160 bits of the scrambled sector are a non-cryptographic hash of the entire plaintext sector.
The second pass uses the NIST Secure Hash Algorithm (FIPS 180, prior to the 180.1 revision) in cipher feedback mode (CFB-160) as a message digest cipher (MDC, as described in Applied Cryptography, pages 171-172), with the last 160 bits of the scrambled sector serving as the initial vector for the encryption pass.
The software includes provisions for wiping plaintext and key material from memory on user command, after a user-selectable time delay (since a given partition was last accessed), or with a single-key "hot key" command.
The software further includes provisions for securely erasing a partition, using multiple overwrite passes designed to minimize residual magnetic remanence, and for decrypting a partition, returning it to service as an unencrypted device.
( 100% New Zealand )
I made three different export applications, based on the country of origin, since I was not sure if Export Controls could reject one item and pass another item within the same application. I have now confirmed that they cannot do this, but, if it does become an issue, you may usually remove one item from the application and get the remaining items approved. Separate applications did allow the Canadian DES code to be approved three months before the other two were. (I now have a stack of applications so every item can be on a separate one next time.)
The MPQS factoring package was included as an experiment. It is not export controlled from the U.S. but I wanted to know what the Canadian government thought about it. They seem to want to control it.
The rather terse description of the DES code, and the lengthy description of SFS were included to test how detailed a description was needed. Foreign Affairs had no problem with any of the descriptions I provided. Apparently they are true to their word and just want enough description to know the true nature of what you wish to export.
On the export application forms, there is a section asking what export restrictions apply. Since I did not think that simply writing in "none" was completely accurate, I also attached a more thorough explanation of my reasoning. The following summarizes these explanations:
The DES software is of Canadian origin and thus is not controlled
by sections 5400 or 5401 of the List, nor does any other section
appear to apply.
Kerberos and MPQS are of United States origin and thus may be
controlled by section 5400 of the List. However, General Export
Permit No. Ex. 12 applies to all goods of U.S. origin, so no
Individual Export Permit should be required.
Peter Gutmann's cryptographic library, and SFS are of New Zealand
origin and thus may be controlled by section 5401 of the List.
Should any of the software be found to be controlled, General
Export Permit No. Ex. 1 (section 3.(a)) nonetheless applies, since
the disk of software is valued at less than $50, obviating the
need for an Individual Export Permit.
All of the software is freely distributable, and thus is
considered "in the public domain" for the purposes of the General
Technology Note, in section 1000 of the Export Control List.
Therefor an export permit is not required.
The DES software is of Canadian origin and thus is not controlled by sections 5400 or 5401 of the List, nor does any other section appear to apply.
Kerberos and MPQS are of United States origin and thus may be controlled by section 5400 of the List. However, General Export Permit No. Ex. 12 applies to all goods of U.S. origin, so no Individual Export Permit should be required.
Peter Gutmann's cryptographic library, and SFS are of New Zealand origin and thus may be controlled by section 5401 of the List.
Should any of the software be found to be controlled, General Export Permit No. Ex. 1 (section 3.(a)) nonetheless applies, since the disk of software is valued at less than $50, obviating the need for an Individual Export Permit.
No export permit is required. I have an export application stamped "This Export Does Not Require an Export Permit", and a letter which explains:
In regards to your Application ... for the export of specific
Canadian origin encryption software to the United Kingdom, I wish to
advise you that this software is currently not controlled by the
Export Control List (ECL) and therefor does not require an export
permit under the Export and Import Permits Act ...
The DES code has a very clear disclaimer on it, even so, the author was contacted by Export Controls to clarify some issues. I cannot blame them for being cautious with my applications, but I personally think that the disclaimer is an excellent example for others. It reads:
 This software (comprised of the files listed above) is
"freeware". It may be freely used and distributed (but see ,
below). The copyright in this software has not been abandoned,
and is hereby asserted.
 ENCRYPTION SOFTWARE MAY ONLY BE EXPORTED FROM NORTH AMERICA
UNDER THE AUTHORITY OF A VALID EXPORT LICENSE OR PERMIT. CONSULT
THE APPROPRIATE BRANCH(ES) OF YOUR FEDERAL GOVERNMENT FOR MORE
 This software is provided "as is" without warranty of
fitness for use or suitability for any purpose, express or
implied. Use at your own risk or not at all. It does, however,
 This software (comprised of the files listed above) is "freeware". It may be freely used and distributed (but see , below). The copyright in this software has not been abandoned, and is hereby asserted.
 ENCRYPTION SOFTWARE MAY ONLY BE EXPORTED FROM NORTH AMERICA UNDER THE AUTHORITY OF A VALID EXPORT LICENSE OR PERMIT. CONSULT THE APPROPRIATE BRANCH(ES) OF YOUR FEDERAL GOVERNMENT FOR MORE INFORMATION.
The final warning is useful, but clearly separate from any restrictions the author places on distribution. The warning now needs some revising. Perhaps:
 Exporting encryption software may require an export licence
or permit. Consult the appropriate branch(es) of your federal
government for more information.
May be exported under the authority of GEP 12. The letter I have explains:
Application ... covering the proposed export to England of DES-based
software and cryptanalytic software, this is controlled under Item
5400 of the Export Control List (ECL). In this regard, an export
permit is required for its export to all countries except the United
States. However, most goods controlled under Item 5400 may be
exported to most destinations under General Export Permit No. EX 12,
a copy of which is enclosed. Please refer to the exceptions contained
in EX 12.
This never quite states that the software may be exported under the authority of GEP 12, but it implies it very strongly -- strongly enough for me.
May be exported under the authority of GEP 12.
I had serious doubts about this one. Export Controls considered MPQS to be cryptanalytic in nature, and therefor controlled. Also there is not a single author to ask, and there is nothing explicitly making the software freely distributable, so it could not safely be considered "in the public domain". However the approval indicates that perhaps it is not just U.S. crypto "in the public domain" that may be exported. (I will have to test this.)
The Canadian export control of MPQS is particularly interesting because export from the U.S. does not seem to be restricted in any way.
No export permit is required. The letter states:
Application ... covering cryptographic software proposed for export
to England, this software is not controlled according to Canada's
ECL. Therefor, provided the product noted in this application is not
of U.S. origin within the meaning of the ECL item 5400, these goods
may be exported to any country, except Libya and Angola, without an
export permit. Please note that most goods to Iraq are still
prohibited at this time, as well.
Same as above; no export permit is required.
My main goal is to try and make it easier for producers of strong encryption to export their goods. Specifically, I would like to be able to legally export PGP. I have one copy of PGP that was brought into Canada in such a way that I believe the ITAR does not restrict its re-export. I also have one copy of PGP which I have no idea how it came into Canada. I have not decided which copy to export. (Why make life easier for the prosecution?)
With the Canadian laws, I think that I will next try to confirm what sorts of restrictions I may place on software, due to copyright law, while still having the software be "in the public domain" as far as export law is concerned. Then I might look at how commercial software may be exported.
I think all of this started based on the suggestion of someone at the Communications Security Establishment (CSE) -- Canada's version of the NSA. He suggested that "If you don't believe me that DES can't be exported, go ahead and try to do it." While a sarcastic civil servant may have caused me to look at the laws, I really did this for more idealistic reasons. Encryption is necessary for business and personal transactions over the Internet, and it should be encouraged not hindered. About five months into the process I also found that I had business reasons to want to export crypto -- that is when I got impatient.
For better or for worse, privacy lets you be yourself.
The people I dealt with at Export Controls, were friendly and helpful, despite my difficult requests and constant nagging. Processing my applications took considerably longer than the usual 2-8 weeks that Export Controls expects. I finally needed to contact the office of the Minister of International Trade to get a decision as quickly as I did. This was a difficult issue, and despite the delays, I think that a decision was reached as quickly as possible. I have been told that the CSE were not happy with the decision, and the entire issue has not been fully resolved yet, so remember that this could change at any time.
This document may be freely distributed. The copyright has not been abandoned. Do not modify or excerpt it without the author's permission, but feel free to distribute it in its entirety.
PGP: F9 27 E4 6C 6D A2 4D BE 97 95 8D 51 0A 90 7A CB