Contents Previous Next

# History and politics of cryptography

Cryptography has a long and interesting history, and has been the subject of considerable political controversy.

## Introduction

### History

The classic book on the history of cryptography is David Kahn's The Codebreakers. It traces codes and codebreaking from ancient Egypt to the 20th century.

Diffie and Landau Privacy on the Line: The Politics of Wiretapping and Encryption covers the history from the First World War to the 1990s, with an emphasis on the US.

#### World War II

During the Second World War, the British "Ultra"project achieved one of the greatest intelligence triumphs in the history of warfare, breaking many Axis codes. One major target was the Enigma cipher machine, a German device whose users were convinced it was unbreakable. The American "Magic" project had some similar triumphs against Japanese codes.

There are many books on this period. See our bibliography for a few, or try a (web or library) search on "Ultra" and "Enigma". Two books I particularly like are:

- Andrew Hodges has done a superb biography of Alan Turing, a key player among the Ultra codebreakers. Turing was also an important computer pioneer. The terms Turing test and Turing machine are named for him, as is the ACM's highest technical award.
- Neal Stephenson's Cryptonomicon is a novel with cryptography central to the plot. Parts of it take place during WW II, other parts today.

Bletchley Park, where much of the Ultra work was done, now has a museum and a web site.

The Ultra work introduced three major innovations.

- The first break of Enigma was achieved by Polish Intelligence in 1931. Until then most code-breakers had been linguists, but a different approach was needed to break machine ciphers. Polish Intelligence realised this, recruited some clever young mathematicians, and succeeded in cracking the "unbreakable" Enigma. When war came in 1939, the Poles told their allies about this, putting Britain on the road to Ultra. The British also adopted a mathematical approach.
- Machines were extensively used in the attacks. First the Polish "Bombe" for attacking Enigma, then British versions of it, then machines such as Collosus for attacking other codes. By the end of the war, some of these machines were beginning to closely resemble digital computers. After the war, a team at Manchester University, several old Ultra hands included, built one of the world's first actual general-purpose digital computers.
- Ultra made codebreaking a large-scale enterprise, producing intelligence on an industrial scale. This was not a "black chamber", not a hidden room in some obscure government building with a small crew of code-breakers. The whole operation -- from wholesale interception of enemy communications by stations around the world, through large-scale code-breaking and analysis of the decrypted material (with an enormous set of files for cross-referencing), to delivery of intelligence to field commanders -- was huge, and very carefully managed.

So by the end of the war, Allied code-breakers were expert at large-scale mechanised code-breaking. The payoffs were enormous.

#### Postwar and Cold War

The wartime innovations were enthusiastically adopted by post-war and Cold War signals intelligence agencies. Presumably many nations now have some agency capable of sophisticated attacks on communications security, and quite a few engage in such activity on a large scale.

America's NSA, for example, is said to be both the world's largest employer of mathematicians and the world's largest purchaser of computer equipment. Such claims may be somewhat exaggerated, but beyond doubt the NSA -- and similar agencies in other countries -- have some excellent mathematicians, lots of powerful computers, sophisticated software, and the organisation and funding to apply them on a large scale. Details of the NSA budget are secret, but there are some published estimates.

Changes in the world's communications systems since WW II have provided these agencies with new targets. Cracking the codes used on an enemy's military or diplomatic communications has been common practice for centuries. Extensive use of radio in war made large-scale attacks such as Ultra possible. Modern communications make it possible to go far beyond that. Consider listening in on cell phones, or intercepting electronic mail, or tapping into the huge volumes of data on new media such as fiber optics or satellite links. None of these targets existed in 1950. All of them can be attacked today, and almost certainly are being attacked.

The Ultra story was not made public until the 1970s. Much of the recent history of codes and code-breaking has not been made public, and some of it may never be. Two important books are:

- Bamford's The Puzzle Palace, a history of the NSA
- Hager's Secret Power, about the Echelon system -- the US, UK, Canada, Australia and New Zealand co-operating to monitor much of the world's communications.

Note that these books cover only part of what is actually going on, and then only the activities of nations open and democratic enough that (some of) what they are doing can be discovered. A full picture, including:

- actions of the English-speaking democracies not covered in those books
- actions of other more-or-less sane governments
- the activities of various more-or-less insane governments
- possibilities for unauthorized action by government employees

might be really frightening.

#### Recent history -- the crypto wars

Until quite recently, cryptography was primarily a concern of governments, especially of the military, of spies, and of diplomats. Much of it was extremely secret.

In recent years, that has changed a great deal. With computers and networking becoming ubiquitous, cryptography is now important to almost everyone. Among the developments since the 1970s:

- The US gov't established the Data Encryption Standard, DES standard, a block cipher for cryptographic protection of unclassfied documents. It has also been widely used in industry.
- Public key cryptography was invented by Diffie and Hellman.
- Academic conferences such as Crypto and Eurocrypt began.
- Several companies began offerring cryptographic products: RSA, PGP, the many vendors with PKI products, ...
- Cryptography appeared in other products: operating systems, word processors, ...
- Network protocols based on crypto were developed: SSH, SSL, IPSEC, ...
- Crytography came into widespread use to secure bank cards, terminals, ...
- The US government replaced DES with the much stronger Advanced Encryption Standard, AES

This has led to a complex ongoing battle between various mainly government groups wanting to control the spread of crypto and various others, notably the computer industry and the "cypherpunk" crypto advocates, wanting to encourage widespread use.

Steven Levy has written a fine history of much of this, called Crypto: How the Code rebels Beat the Government -- Saving Privacy in the Digital Age.

The FreeS/WAN project is to a large extent an outgrowth of cypherpunk ideas. Our reasons for doing the project can be seen in these quotes from the Cypherpunk Manifesto:

> Privacy is necessary for an open society in the electronic age. ...

> We cannot expect governments, corporations, or other large, faceless organizations to grant us privacy out of their beneficence. It is to their advantage to speak of us, and we should expect that they will speak. ...

> We must defend our own privacy if we expect to have any. ...

> Cypherpunks write code. We know that someone has to write software to defend privacy, and since we can't get privacy unless we all do, we're going to write it. We publish our code so that our fellow Cypherpunks may practice and play with it. Our code is free for all to use, worldwide. We don't much care if you don't approve of the software we write. We know that software can't be destroyed and that a widely dispersed system can't be shut down.

> Cypherpunks deplore regulations on cryptography, for encryption is fundamentally a private act. ...

> For privacy to be widespread it must be part of a social contract. People must come and together deploy these systems for the common good. ...

To quote project leader John Gilmore:

> We are literally in a race between our ability to build and deploy technology, and their ability to build and deploy laws and treaties. Neither side is likely to back down or wise up until it has definitively lost the race.

If FreeS/WAN reaches its goal of making opportunistic encryption widespread so that secure communication can become the default for a large part of the net, we will have struck a major blow.

### Politics

The political problem is that nearly all governments want to monitor their enemies' communications, and some want to monitor their citizens. They may be very interested in protecting some of their own communications, and often some types of business communication, but not in having everyone able to communicate securely. They therefore attempt to restrict availability of strong cryptography as much as possible.

Things various governments have tried or are trying include:

- Echelon, a monitor-the-world project of the US, UK, NZ, Australian and Canadian signals intelligence agencies. See this collection of links and this story on the French Parliament's reaction.
- Others governments may well have their own Echelon-like projects. To quote the Dutch Minister of Defense, as reported in a German magazine:

  > The government believes not only the governments associated with Echelon are able to intercept communication systems, but that it is an activity of the investigative authorities and intelligence services of many countries with governments of different political signature.

  Even if they have nothing on the scale of Echelon, most intelligence agencies and police forces certainly have some interception capability.
- NSA tapping of submarine communication cables, described in this article
- A proposal for international co-operation on Internet surveillance.
- Alleged sabotage of security products by the NSA (the US signals intelligence agency).
- The German armed forces and some government departments will stop using American software for fear of NSA "back doors", according to this news story.
- The British Regulation of Investigatory Powers bill. See this web page. and perhaps this cartoon.
- A Russian ban on cryptography
- Chinese controls on net use.
- The FBI's carnivore system for covert searches of email. See this news coverage and this risk assessment. The government had an external review of some aspects of this system done. See this analysis of that review. Possible defenses against Carnivore include:
  - PGP for end-to-end mail encryption
  - secure sendmail for server-to-server encryption
  - IPSEC encryption on the underlying IP network
- export laws restricting strong cryptography as a munition. See discussion below.
- various attempts to convince people that fundamentally flawed cryptography, such as encryption with a back door for government access to data or with inadequate key lengths, was adequate for their needs.

Of course governments are by no means the only threat to privacy and security on the net. Other threats include:

- industrial espionage, as for example in this news story
- attacks by organised criminals, as in this large-scale attack
- collection of personal data by various companies.
  - for example, consider the various corporate winners of Privacy International's Big Brother Awards.
  - Zero Knowledge sell tools to defend against this
- individuals may also be a threat in a variety of ways and for a variety of reasons
- in particular, an individual with access to government or industry data collections could do considerable damage using that data in unauthorized ways.

One study enumerates threats and possible responses for small and medium businesses. VPNs are a key part of the suggested strategy.

We consider privacy a human right. Our objective is to help make privacy possible on the Internet using cryptography strong enough not even those well-funded government agencies are likely to break it. If we can do that, the chances of anyone else breaking it are negliible.

### Links

Many groups are working in different ways to defend privacy on the net and elsewhere. Please consider contributing to one or more of these groups:

- the EFF's Privacy Now! campaign
- the Global Internet Liberty Campaign
- Computer Professionals for Social Responsibility

For more on these issues see:

- Steven Levy (Newsweek's chief technology writer and author of the classic "Hackers") new book Crypto: How the Code Rebels Beat the Government--Saving Privacy in the Digital Age
- Simson Garfinkel (Boston Globe columnist and author of books on PGP and Unix Security) book Database Nation: the death of privacy in the 21st century
- an interview with Eblen Morgan (general counsel to the Free Software Foundation and a professor at Columbia Law School) on the "encryption wars".

See also the bibliography and our list of web references on cryptography law and policy.

### Outline of this section

The remainder of this section includes two pieces of writing by our project leader

- his rationale for starting this
- another discussion of project goals

and discussions of:

- why we do not use DES
- cryptography export laws
- why government access to keys is not a good idea
- the myth that short keys are adequate for some security requirements

and a section on press coverage of FreeS/WAN.

## From our project leader

FreeS/WAN project founder John Gilmore wrote a web page about why we are doing this. The version below is slightly edited, to fit this format and to update some links. For a version without these edits, see his home page.

### Swan: Securing the Internet against Wiretapping

My project for 1996 was to secure 5% of the Internet traffic against passive wiretapping. It didn't happen in 1996, so I'm still working on it in 1997, 1998, and 1999! If we get 5% in 1999 or 2000, we can secure 20% the next year, against both active and passive attacks; and 80% the following year. Soon the whole Internet will be private and secure. The project is called S/WAN or S/Wan or Swan for Secure Wide Area Network; since it's free software, we call it FreeSwan to distinguish it from various commercial implementations. RSA came up with the term "S/WAN". Our main web site is at http://www.freeswan.org/. Want to help?

The idea is to deploy PC-based boxes that will sit between your local area network and the Internet (near your firewall or router) which opportunistically encrypt your Internet packets. Whenever you talk to a machine (like a Web site) that doesn't support encryption, your traffic goes out "in the clear" as usual. Whenever you connect to a machine that does support this kind of encryption, this box automatically encrypts all your packets, and decrypts the ones that come in. In effect, each packet gets put into an "envelope" on one side of the net, and removed from the envelope when it reaches its destination. This works for all kinds of Internet traffic, including Web access, Telnet, FTP, email, IRC, Usenet, etc.

The encryption boxes are standard PC's that use freely available Linux software that you can download over the Internet or install from a cheap CDROM.

This wasn't just my idea; lots of people have been working on it for years. The encryption protocols for these boxes are called IPSEC (IP Security). They have been developed by the IP Security Working Group of the Internet Engineering Task Force, and will be a standard part of the next major version of the Internet protocols ( IPv6). For today's (IP version 4) Internet, they are an option.

The Internet Architecture Board and Internet Engineering Steering Group have taken a strong stand that the Internet should use powerful encryption to provide security and privacy. I think these protocols are the best chance to do that, because they can be deployed very easily, without changing your hardware or software or retraining your users. They offer the best security we know how to build, using the Triple-DES, RSA, and Diffie-Hellman algorithms.

This "opportunistic encryption box" offers the "fax effect". As each person installs one for their own use, it becomes more valuable for their neighbors to install one too, because there's one more person to use it with. The software automatically notices each newly installed box, and doesn't require a network administrator to reconfigure it. Instead of "virtual private networks" we have a "REAL private network"; we add privacy to the real network instead of layering a manually-maintained virtual network on top of an insecure Internet.

#### Deployment of IPSEC

The US government would like to control the deployment of IP Security with its crypto export laws. This isn't a problem for my effort, because the cryptographic work is happening outside the United States. A foreign philanthropist, and others, have donated the resources required to add these protocols to the Linux operating system. Linux is a complete, freely available operating system for IBM PC's and several kinds of workstation, which is compatible with Unix. It was written by Linus Torvalds, and is still maintained by a talented team of expert programmers working all over the world and coordinating over the Internet. Linux is distributed under the GNU Public License, which gives everyone the right to copy it, improve it, give it to their friends, sell it commercially, or do just about anything else with it, without paying anyone for the privilege.

Organizations that want to secure their network will be able to put two Ethernet cards into an IBM PC, install Linux on it from a $30 CDROM or by downloading it over the net, and plug it in between their Ethernet and their Internet link or firewall. That's all they'll have to do to encrypt their Internet traffic everywhere outside their own local area network.

Travelers will be able to run Linux on their laptops, to secure their connection back to their home network (and to everywhere else that they connect to, such as customer sites). Anyone who runs Linux on a standalone PC will also be able to secure their network connections, without changing their application software or how they operate their computer from day to day.

There will also be numerous commercially available firewalls that use this technology. RSA Data Security is coordinating the S/Wan (Secure Wide Area Network) project among more than a dozen vendors who use these protocols. There's a compatability chart that shows which vendors have tested their boxes against which other vendors to guarantee interoperatility.

Eventually it will also move into the operating systems and networking protocol stacks of major vendors. This will probably take longer, because those vendors will have to figure out what they want to do about the export controls.

#### Current status

My initial goal of securing 5% of the net by Christmas '96 was not met. It was an ambitious goal, and inspired me and others to work hard, but was ultimately too ambitious. The protocols were in an early stage of development, and needed a lot more protocol design before they could be implemented. As of April 1999, we have released version 1.0 of the software ( freeswan-1.0.tar.gz), which is suitable for setting up Virtual Private Networks using shared secrets for authentication. It does not yet do opportunistic encryption, or use DNSSEC for authentication; those features are coming in a future release.

Protocols
  The low-level encrypted packet formats are defined. The system for publishing keys and providing secure domain name service is defined. The IP Security working group has settled on an NSA-sponsored protocol for key agreement (called ISAKMP/Oakley), but it is still being worked on, as the protocol and its documentation is too complex and incomplete. There are prototype implementations of ISAKMP. The protocol is not yet defined to enable opportunistic encryption or the use of DNSSEC keys.
Linux Implementation
  The Linux implementation has reached its first major release and is ready for production use in manually-configured networks, using Linux kernel version 2.0.36.
Domain Name System Security
  There is now a release of BIND 8.2 that includes most DNS Security features.

The first prototype implementation of Domain Name System Security was funded by DARPA as part of their Information Survivability program. Trusted Information Systems wrote a modified version of BIND, the widely-used Berkeley implementation of the Domain Name System.

TIS, ISC, and I merged the prototype into the standard version of BIND. The first production version that supports KEY and SIG records is bind-4.9.5. This or any later version of BIND will do for publishing keys. It is available from the Internet Software Consortium. This version of BIND is not export-controlled since it does not contain any cryptography. Later releases starting with BIND 8.2 include cryptography for authenticating DNS records, which is also exportable. Better documentation is needed.

#### Why?

Because I can. I have made enough money from several successful startup companies, that for a while I don't have to work to support myself. I spend my energies and money creating the kind of world that I'd like to live in and that I'd like my (future) kids to live in. Keeping and improving on the civil rights we have in the United States, as we move more of our lives into cyberspace, is a particular goal of mine.

#### What You Can Do

Install the latest BIND at your site.
  You won't be able to publish any keys for your domain, until you have upgraded your copy of BIND. The thing you really need from it is the new version of named, the Name Daemon, which knows about the new KEY and SIG record types. So, download it from the Internet Software Consortium and install it on your name server machine (or get your system administrator, or Internet Service Provider, to install it). Both your primary DNS site and all of your secondary DNS sites will need the new release before you will be able to publish your keys. You can tell which sites this is by running the Unix command "dig MYDOMAIN ns" and seeing which sites are mentioned in your NS (name server) records.
Set up a Linux system and run a 2.0.x kernel on it
  Get a machine running Linux (say the 5.2 release from Red Hat). Give the machine two Ethernet cards.
Install the Linux IPSEC (Freeswan) software
  If you're an experienced sysadmin or Linux hacker, install the freeswan-1.0 release, or any later release or snapshot. These releases do NOT provide automated "opportunistic" operation; they must be manually configured for each site you wish to encrypt with.
Get on the linux-ipsec mailing list
  The discussion forum for people working on the project, and testing the code and documentation, is: linux-ipsec@clinet.fi. To join this mailing list, send email to linux-ipsec-REQUEST@clinet.fi containing a line of text that says "subscribe linux-ipsec". (You can later get off the mailing list the same way -- just send "unsubscribe linux-ipsec").

Check back at this web page every once in a while
  I update this page periodically, and there may be new information in it that you haven't seen. My intent is to send email to the mailing list when I update the page in any significant way, so subscribing to the list is an alternative.

Would you like to help? I can use people who are willing to write documentation, install early releases for testing, write cryptographic code outside the United States, sell pre-packaged software or systems including this technology, and teach classes for network administrators who want to install this technology. To offer to help, send me email at gnu@toad.com. Tell me what country you live in and what your citizenship is (it matters due to the export control laws; personally I don't care). Include a copy of your resume and the URL of your home page. Describe what you'd like to do for the project, and what you're uniquely qualified for. Mention what other volunteer projects you've been involved in (and how they worked out). Helping out will require that you be able to commit to doing particular things, meet your commitments, and be responsive by email. Volunteer projects just don't work without those things.

#### Related projects

IPSEC for NetBSD
  This prototype implementation of the IP Security protocols is for another free operating system. Download BSDipsec.tar.gz.
IPSEC for OpenBSD
  This prototype implementation of the IP Security protocols is for yet another free operating system. It is directly integrated into the OS release, since the OS is maintained in Canada, which has freedom of speech in software.

### Stopping wholesale monitoring

From a message project leader John Gilmore posted to the mailing list:

    John Denker wrote:

    > Indeed there are several ways in which the documentation overstates the
    > scope of what this project does -- starting with the name
    > FreeS/WAN.  There's a big difference between having an encrypted IP tunnel
    > versus having a Secure Wide-Area Network.  This software does a fine job of
    > the former, which is necessary but not sufficient for the latter.

    The goal of the project is to make it very hard to tap your wide area
    communications.  The current system provides very good protection
    against passive attacks (wiretapping and those big antenna farms).
    Active attacks, which involve the intruder sending packets to your
    system (like packets that break into sendmail and give them a root
    shell :-) are much harder to guard against.  Active attacks that
    involve sending people (breaking into your house and replacing parts
    of your computer with ones that transmit what you're doing) are also
    much harder to guard against.  Though we are putting effort into
    protecting against active attacks, it's a much bigger job than merely
    providing strong encryption.  It involves general computer security,
    and general physical security, which are two very expensive problems
    for even a site to solve, let alone to build into a whole society.

    The societal benefit of building an infrastructure that protects
    well against passive attacks is that it makes it much harder to do
    undetected bulk monitoring of the population.  It's a defense against
    police-states, not against policemen.

    Policemen can put in the effort required to actively attack sites that
    they have strong suspicions about.  But police states won't be able to
    build systems that automatically monitor everyone's communications.
    Either they will be able to monitor only a small subset of the
    populace (by targeting those who screwed up their passive security),
    or their monitoring activities will be detectable by those monitored
    (active attacks leave packet traces or footprints), which can then be
    addressed through the press and through political means if they become
    too widespread.

    FreeS/WAN does not protect very well against traffic analysis, which
    is a kind of widespread police-state style monitoring that still
    reveals significant information (who's talking to who) without
    revealing the contents of what was said.  Defenses against traffic
    analysis are an open research problem.  Zero Knowledge Systems is
    actively deploying a system designed to thwart it, designed by Ian
    Goldberg.  The jury is out on whether it actually works; a lot more
    experience with it will be needed.

Notes on things mentioned in that message:

- Denker is a co-author of a paper on a large FreeS/WAN application.
- Information on Zero Knowledge is on their web site. Their Freedom product is designed to provide untracable pseudonyms for use on the net.
- Another section of our documentation discusses ways to resist traffic analysis.

## Government promotion of weak crypto

Various groups, especially governments and especially the US government, have a long history of advocating various forms of bogus security.

We regard bogus security as extremely dangerous. If users are deceived into relying on bogus security, then they may be exposed to large risks. They would be better off having no security and knowing it. At least then they would be careful about what they said.

Avoiding bogus security is a key design criterion for everything we do in FreeS/WAN. The most conspicuous example is our refusal to support single DES. Other IPSEC "features" which we do not implement are discussed in our compatibility document.

### Escrowed encryption

Various governments have made persistent attempts to encourage or mandate "escrowed encrytion", also called "key recovery", or GAK for "government access to keys". The idea is that cryptographic keys be held by some third party and turned over to law enforcement or security agencies under some conditions.

      Mary had cryptography
      Her keys were in escrow
      And everything that Mary said
      The feds were sure to know

(If anyone knows the origin of that ditty, let let me know so I can credit the author.)

There is an excellent paper available on Risks of Escrowed Encryption, from a group of cryptographic luminaries which included our project leader.

Like any unnecessary complication, GAK tends to weaken security of any design it infects. For example:

- Matt Blaze found a fatal flaw in the US government's Clipper chip shortly after design information became public. See his paper "Protocol Failure in the Escrowed Encryption Standard" on his papers page.
- a rather nasty bug has recently been found in the "additional decryption keys" "feature" of recent releases of PGP

FreeS/WAN does not support escrowed encryption, and never will.

### Limited key lengths

Various governments, and some vendors, have also made persistent attempts to convince people that:

- weak systems are sufficient for some data
- strong cryptography should be reserved for cases where the extra overheads are justified

This is nonsense.

Weak systems touted include:

- the ludicrously weak (deliberately crippled) 40-bit ciphers that until recently were all various export laws allowed
- 56-bit single DES, discussed below
- 64-bit symmetric ciphers and 512-bit RSA, the maximums for unrestricted export under various current laws

The notion that choice of ciphers or keysize should be determined by a trade-off between security requirements and overheads is pure bafflegab.

- For most symmetric ciphers, it is simply a lie. Any block cipher has some natural maximum keysize inherent in the design -- 128 bits for IDEA or CAST-128, 256 for any of the AES ciphers, 448 for Blowfish and 2048 for RC4. Using any key size up to that natural limit the overheads are exactly what they would be for the crippled 40-bit or 64-bit version of the cipher.
- For the special case of triple DES there is a grain of truth in the argument. 3DES is indeed three times slower than single DES. Of course it is also fast enough for many applications. In cases where it isn't, the solution is not to use the insecure single DES, but to pick a faster secure cipher. CAST-128, Blowfish and the AES candidate ciphers are are all considerably faster in software than DES (let alone 3DES), and apparently secure.
- For public key techniques, there are extra overheads for larger keys, but they generally do not affect overall performance significantly. Practical public key applications are usually hybrid systems in which the bulk of the work is done by a symmetric cipher. The effect of increasing the cost of the public key operations is typically negligible because the public key operations use only a tiny fraction of total resources.

For example, suppose public key operations use use 1% of the time in a hybrid system and you triple the cost of public key operations. The cost of symmetric cipher operations is unchanged at 99% of the original total cost, so the overall effect is a jump from 99 + 1 = 100 to 99 + 3 = 102, a 2% rise in system cost.

In short, there has never been any technical reason to use inadequate ciphers. The only reason there has ever been for anyone to use such ciphers is that government agencies want weak ciphers used so that they can crack them. The alleged savings are simply propaganda.

Of course, making systems secure does involve costs, and trade-offs can be made between cost and security. There can be substantial hardware and software costs. There are almost always substantial staff or contracting costs:

- Security takes staff time for planning, implementation and auditing. Some of the issues are subtle; you need good (hence often expensive) people for this.
- You also need people to monitor your systems and respond to problems. The best safe ever built is insecure if an attacker can work on it for days without anyone noticing. Any computer is insecure if the administrator is "too busy" to check the logs.
- Moreover, someone in your organisation (or on contract to it) needs to spend considerable time keeping up with new developments.
  - When some novel attack threatens some program you use, someone should notice.
  - When the vendor provides a patch that fixes the vulnerability, someone should apply it.

  For a fairly awful example, see this report. In that case over a million credit card numbers were taken from e-commerce sites, using security flaws in Windows NT servers. Microsoft had long since released patches for most or all of the flaws, but the site administrators had not applied them.

  - If the vendor does nothing, someone should do at least one of:
    - raise hell with the vendor
    - raise the question of changing vendors
  At an absolute minimum, you must do something about such issues before an exploitation tool is posted to the net for downloading by dozens of "script kiddies". Such a tool might appear at any time from the announcement of the security hole to several months later. Once it appears, anyone with a browser and an attitude can break any system whose administrators have done nothing about the flaw.
- There are often substantial training costs, both to train administrators and to increase user awareness of security issues and procedures.

Compared to those costs, cipher overheads are an insignificant factor in the cost of security. Note, however, that choosing an insecure cipher can cause all your other investment to be wasted.

Our policy in FreeS/WAN is to use only cryptographic components with adequate keylength and no known weaknesses.

- We do not implement single DES because it is clearly insecure, so implemeting it would violate our policy of avoiding bogus security. Our default cipher is 3DES
- Similarly, we do not implement the 768-bit Group 1 for Diffie-Hellman key negotiation. It is not clear that this is secure, so we provide only the 1024-bit Group 2 and 1536-bit Group 5.

These decisions imply that we cannot fully conform to the IPSEC RFCs, since those have DES as the only required cipher and Group 1 as the only required DH group. (In our view, the standards were subverted into offerring bogus security.) Fortunately, we can still interoperate with most other IPSEC implementations since nearly all implementers provide at least 3DES and Group 2 as well.

We hope that eventually the RFCs will catch up with our (and others') current practice and reject dubious components. Some of our team and a number of others are working on this in IETF working groups.

## Cryptography Export Laws

Many nations restrict the export of cryptography and some restrict its use by their citizens or others within their borders.

### US Law

US laws, as currently interpreted by the US government, forbid export of most cryptographic software from the US in machine-readable form without government permission. In general, the restrictions apply even if the software is widely-disseminated or public-domain and even if it came from outside the US originally. Cryptography is legally a munition and export is tightly controlled under the EAR Export Administration Regulations.

If you are a US citizen, your brain is considered US territory no matter where it is physically located at the moment. The US believes that its laws apply to its citizens everywhere, not just within the US. Providing technical assistance or advice to foreign "munitions" projects is illegal. The US government has very little sense of humor about this issue and does not consider good intentions to be sufficient excuse. Beware.

The official website for these regulations is run by the Commerce Department's Bureau of Export Administration (BXA). Information on various challenges to them is indexed in the Cryptography Export Control Archives.

The Bernstein case challenges the export restrictions on Constitutional grounds. Code is speech so restrictions on export of code violate the First Amendment's free speech provisions. This argument has succeeded in two levels of court so far. It is quite likely to go on to the Supreme Court.

The regulations were changed substantially in January 2000, apparently as a government attempt to get off the hook in the Bernstein case. It is now legal to export public domain source code for encryption, provided you notify the BXA .

There are, however, still restrictions in force. See this article. Moreover, the regulations can still be changed again whenever the government chooses to do so. Short of a Supreme Court ruling (in the Berstein case or another) that overturns the regulations completely, the problem of export regulation is not likely to go away in the forseeable future.

#### US contributions to FreeS/WAN

The FreeS/WAN project cannot accept software contributions, not even small bug fixes, from US citizens or residents. We want it to be absolutely clear that our distribution is not subject to US export law. Any contribution from an American might open that question to a debate we'd prefer to avoid. It might also put the contributor at serious legal risk.

Of course Americans can still make valuable contributions (many already have) by reporting bugs, or otherwise contributing to discussions, on the project mailing list. Since the list is public, this is clearly constitutionally protected free speech.

Note, however, that the export laws restrict Americans from providing technical assistance to foreign "munitions" projects. The government might claim that private discussions or correspondence with FreeS/WAN developers were covered by this. It is not clear what the courts would do with such a claim, so we strongly encourage Americans to use the list rather than risk the complications.

### What's wrong with restrictions on cryptography

Some quotes from prominent cryptography experts:

> The real aim of current policy is to ensure the continued effectiveness of US information warfare assets against individuals, businesses and governments in Europe and elsewhere.
> Ross Anderson, Cambridge University

> If the government were honest about its motives, then the debate about crypto export policy would have ended years ago.
> Bruce Schneier, Counterpane Systems

> We should not be building surveillance technology into standards. Law enforcement was not supposed to be easy. Where it is easy, it's called a police state.
> Jeff Schiller of MIT, in a discussion of FBI demands for wiretap capability on the net, as quoted by Wired.

The Internet Architecture Board (IAB) and the Internet Engineering Steering Group (IESG) made a strong statement in favour of worldwide access to strong cryptography. Essentially the same statement is in the appropriately numbered RFC 1984. Two critical paragraphs are:

> We believe that such policies are against the interests of consumers and the business community, are largely irrelevant to issues of military security, and provide only a marginal or illusory benefit to law enforcement agencies, as discussed below.

> The IAB and IESG would like to encourage policies that allow ready access to uniform strong cryptographic technology for all Internet users in all countries.

Our goal in the FreeS/WAN project is to build just such "strong cryptographic technology" and to distribute it "for all Internet users in all countries".

More recently, the same two bodies (IESG and IAB) have issued RFC 2804 on why the IETF should not build wiretapping capabilities into protocols for the convenience of security or law enforcement agenicies.

Our goal is to go beyond that and prevent Internet wiretapping entirely.

### The Wassenaar Arrangement

Restrictions on the export of cryptography are not just US policy, though some consider the US at least partly to blame for the policies of other nations in this area.

A number of countries:

Argentina, Australia, Austria, Belgium, Bulgaria, Canada, Czech Republic, Denmark, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Japan, Luxembourg, Netherlands, New Zealand, Norway, Poland, Portugal, Republic of Korea, Romania, Russian Federation, Slovak Republic, Spain, Sweden, Switzerland, Turkey, Ukraine, United Kingdom and United States

have signed the Wassenaar Arrangement which restricts export of munitions and other tools of war. Cryptographic sofware is covered there.

Wassenaar details are available from the Wassenaar Secretariat, and elsewhere in a more readable HTML version.

For a critique see the GILC site:

> The Global Internet Liberty Campaign (GILC) has begun a campaign calling for the removal of cryptography controls from the Wassenaar Arrangement.

> The aim of the Wassenaar Arrangement is to prevent the build up of military capabilities that threaten regional and international security and stability . . .

> There is no sound basis within the Wassenaar Arrangement for the continuation of any export controls on cryptographic products.

We agree entirely.

An interesting analysis of Wassenaar can be found on the cyber-rights.org site.

### Export status of Linux FreeS/WAN

We believe our software is entirely exempt from these controls since the Wassenaar General Software Note says:

> The Lists do not control "software" which is either:
> 1. Generally available to the public by . . . retail . . . or
> 2. "In the public domain".

There is a note restricting some of this, but it is a sub-heading under point 1, so it appears not to apply to public domain software.

Their glossary defines "In the public domain" as:

> . . . "technology" or "software" which has been made available without restrictions upon its further dissemination.

> N.B. Copyright restrictions do not remove "technology" or "software" from being "in the public domain".

We therefore believe that software freely distributed under the GNU Public License, such as Linux FreeS/WAN, is exempt from Wassenaar restrictions.

Most of the development work is being done in Canada. Our understanding is that the Canadian government accepts this interpretation.

- A web statement of Canadian policy is available from the Department of Foreign Affairs and International Trade.
- Another document from that department states that public domain software is exempt from the export controls.
- A researcher's analysis of Canadian policy is also available.

Recent copies of the freely modifiable and distributable source code exist in many countries. Citizens all over the world participate in its use and evolution, and guard its ongoing distribution. Even if Canadian policy were to change, the software would continue to evolve in countries which do not restrict exports, and would continue to be imported from there into unfree countries. "The Net culture treats censorship as damage, and routes around it."

### Help spread IPSEC around

You can help. If you don't know of a Linux FreeS/WAN archive in your own country, please download it now to your personal machine, and consider making it publicly accessible if that doesn't violate your own laws. If you have the resources, consider going one step further and setting up a mirror site for the whole munitions Linux crypto software archive.

If you make Linux CD-ROMs, please consider including this code, in a way that violates no laws (in a free country, or in a domestic-only CD product).

Please send a note about any new archive mirror sites or CD distributions to linux-ipsec@clinet.fi so we can update the documentation.

Lists of current mirror sites and of distributions which include FreeS/WAN are in our introduction section.

## DES is Not Secure

DES, the Data Encryption S tandard, can no longer be considered secure. While no major flaws in its innards are known, it is fundamentally inadequate because its 56-bit key is too short. It is vulnerable to brute-force search of the whole key space, either by large collections of general-purpose machines or even more quickly by specialized hardware. Of course this also applies to any other cipher with only a 56-bit key. The only reason anyone could have for using a 56 or 64-bit key is to comply with various export laws intended to ensure the use of breakable ciphers.

Non-government cryptologists have been saying DES's 56-bit key was too short for some time -- some of them were saying it in the 70's when DES became a standard -- but the US government has consistently ridiculed such suggestions.

A group of well-known cryptographers looked at key lengths in a 1996 paper. They suggested a minimum of 75 bits to consider an existing cipher secure and a minimum of 90 bits for new ciphers. More recent papers, covering both symmetric and public key systems are at cryptosavvy.com and rsa.com. For all algorithms, the minimum keylengths recommended in such papers are significantly longer than the maximums allowed by various export laws.

In a 1998 ruling, a German court described DES as "out-of-date and not safe enough" and held a bank liable for using it.

### Dedicated hardware breaks DES in a few days

The question of DES security has now been settled once and for all. In early 1998, the Electronic Frontier Foundation built a DES-cracking machine. It can find a DES key in an average of a few days' search. The details of all this, including complete code listings and complete plans for the machine, have been published in Cracking DES, by the Electronic Frontier Foundation.

That machine cost just over $200,000 to design and build. "Moore's Law" is that machines get faster (or cheaper, for the same speed) by roughly a factor of two every 18 months. At that rate, their $200,000 in 1998 becomes $50,000 in 2001.

However, Moore's Law is not exact and the $50,000 estimate does not allow for the fact that a copy based on the published EFF design would of course cost far less than the original. We cannot say exactly what such a cracker would cost today, but it would likely be somewhere between $10,000 and $100,000.

A large corporation could build one of these out of petty cash. The cost is low enough for a senior manager to hide it in a departmental budget and avoid having to announce or justify the project. Any government agency, from a major municipal police force up, could afford one. Or any other group with a respectable budget -- criminal organisations, political groups, labour unions, religious groups, ... Or any millionaire with an obsession or a grudge, or just strange taste in toys.

One might wonder if a private security or detective agency would have one for rent. They wouldn't need many clients to pay off that investment.

### Spooks may break DES faster yet

As for the security and intelligence agencies of various nations, some of them may have had DES crackers for years. Possibly very fast ones! Cipher-cracking is one of the few known applications which is easy to speed up by just adding more processors and memory. Within very broad limits, you can make it as fast as you like if you have the budget. The EFF's $200,000 machine breaks DES in a few days. An aviation website gives the cost of a B1 bomber as $200,000,000. Spending that much, an intelligence agency could expect to break DES in an average time of six and a half minutes.

That estimate assumes they use the EFF's 1998 technology and just spend more money. They may have an attack that is superior to brute force, they quite likely have better chip technology (Moore's law, a bigger budget, and whatever secret advances they may have made) and of course they may have spent the price of an aircraft carrier, not just one aircraft.

In short, we have no idea how quickly these organisations can break DES. Unless they're grossly incompetent, they can certainly do it more quickly than the users of the cipher would like, but beyond that we can't say. Pick any time unit between days and milliseconds. None of these is entirely unbelievable. More to the point, none of them is of any comfort if you don't want such organisations reading your communications.

Note that this may be a concern even if nothing you do is a threat to anyone's national security. An intelligence agency might well consider it to be in their national interest for certain companies to do well. If you're competing against such companies in a world market and that agency can read your secrets, you have a serious problem. For example, see this NBC story or this analysis. The US are the villains in those pieces, but there is no reason to imagine they are the only threat.

One might wonder about technology the former Soviet Union and its allies developed for cracking DES during the Cold War. They must have tried; the cipher was an American standard and widely used. How well did they succeed? Is their technology now for sale or rent?

### Networks break DES in a few weeks

Before the definitive EFF effort, DES had been cracked several times by people using many machines. See this press release for example.

A major corporation, university, or government department could break DES by using spare cycles on their existing collection of computers, by dedicating a group of otherwise surplus machines to the problem, or by combining the two approaches. It might take them weeks or months, rather than the days required for the EFF machine, but they could do it.

What about someone working alone, without the resources of a large organisation? For them, cracking DES will not be easy, but it may be possible. A few thousand dollars buys a lot of surplus workstations. A pile of such machines will certainly heat your garage nicely and might break DES in a few months or years. Or enroll at a university and use their machines. Or use an employer's machines. Or crack security somewhere and steal the resources to crack a DES key. Or write a virus that steals small amounts of resources on many machines. Or . . .

None of these approaches are easy or break DES really quickly, but an attacker only needs to find one that is feasible and breaks DES quickly enough to be dangerous. How much would you care to bet that this will be impossible if the attacker is clever and determined? How valuable is your data? Are you authorised to risk it on a dubious bet?

### We disable DES

In short, it is now absolutely clear that DES is not secure against

- any well-funded opponent
- any opponent (even a penniless one) with access (even stolen access) to enough general purpose computers

That is why Linux FreeS/WAN disables all transforms which use plain DES for encryption.

DES is in the source code, because we need DES to implement our default encryption transform, Triple DES . We urge you not to use single DES. We do not provide any easy way to enable it in FreeS/WAN, and our policy is to provide no assistance to anyone wanting to do so.

### 40-bits is laughably weak

The same is true, in spades, of ciphers -- DES or others -- crippled by 40-bit keys, as many ciphers were required to be until recently under various export laws. A brute force search of such a cipher's keyspace is 216 times faster than a similar search against DES. The EFF's machine can do a brute-force search of a 40-bit key space in seconds. One contest to crack a 40-bit cipher was won by a student using a few hundred idle machines at his university. It took only three and half hours.

We do not, and will not, implement any 40-bit cipher.

### Triple DES is almost certainly secure

Triple DES, usually abbreviated 3DES, applies DES three times, with three different keys. DES seems to be basically an excellent cipher design; it has withstood several decades of intensive analysis without any disastrous flaws being found. It's only major flaw is that the small keyspace allows brute force attacks to succeeed. Triple DES enlarges the key space to 168 bits, making brute-force search a ridiculous impossibility.

3DES is currently the only block cipher implemented in FreeS/WAN. 3DES is, unfortunately, about 1/3 the speed of DES, but modern CPUs still do it at quite respectable speeds. Some speed measurements for our code are available.

### AES in IPSEC

The AES project has recently chosen a replacement for DES, a new standard cipher for use in non-classified US government work and in regulated industries such as banking. This cipher will almost certainly become widely used for many applications, including IPSEC, but perhaps not quickly.

The winner, announced in October 2000 after several years of analysis and discussion, was the Rijndael cipher from two Belgian designers.

It is likely that many IPSEC implementations will add Rijndael support over the next few months or years. FreeS/WAN will almost certainly do so, but it is not high on the priority list. This might be an excellent project for a volunteer.

## Press coverage of Linux FreeS/WAN:

### FreeS/WAN 1.0 press

- Wired "Linux-Based Crypto Stops Snoops", James Glave April 15 1999
- Slashdot
- DGL, Damar Group Limited; looking at FreeS/WAN from a perspective of business computing
- Linux Today
- TBTF , Tasty Bits from the Technology Front
- Salon Magazine "Free Encryption Takes a Big Step"

### Press release for version 1.0

            Strong Internet Privacy Software Free for Linux Users Worldwide

    Toronto, ON, April 14, 1999 -

    The Linux FreeS/WAN project today released free software to protect
    the privacy of Internet communications using strong encryption codes.
    FreeS/WAN automatically encrypts data as it crosses the Internet, to
    prevent unauthorized people from receiving or modifying it.  One
    ordinary PC per site runs this free software under Linux to become a
    secure gateway in a Virtual Private Network, without having to modify
    users' operating systems or application software.  The project built
    and released the software outside the United States, avoiding US
    government regulations which prohibit good privacy protection.
    FreeS/WAN version 1.0 is available immediately for downloading at
    http://www.xs4all.nl/~freeswan/.

    "Today's FreeS/WAN release allows network administrators to build
    excellent secure gateways out of old PCs at no cost, or using a cheap
    new PC," said John Gilmore, the entrepreneur who instigated the
    project in 1996.  "They can build operational experience with strong
    network encryption and protect their users' most important
    communications worldwide."

    "The software was written outside the United States, and we do not
    accept contributions from US citizens or residents, so that it can be
    freely published for use in every country," said Henry Spencer, who
    built the release in Toronto, Canada.  "Similar products based in the
    US require hard-to-get government export licenses before they can be
    provided to non-US users, and can never be simply published on a Web
    site.  Our product is freely available worldwide for immediate
    downloading, at no cost."

    FreeS/WAN provides privacy against both quiet eavesdropping (such as
    "packet sniffing") and active attempts to compromise communications
    (such as impersonating participating computers).  Secure "tunnels" carry
    information safely across the Internet between locations such as a
    company's main office, distant sales offices, and roaming laptops.  This
    protects the privacy and integrity of all information sent among those
    locations, including sensitive intra-company email, financial transactions
    such as mergers and acquisitions, business negotiations, personal medical
    records, privileged correspondence with lawyers, and information about
    crimes or civil rights violations.  The software will be particularly
    useful to frequent wiretapping targets such as private companies competing
    with government-owned companies, civil rights groups and lawyers,
    opposition political parties, and dissidents.

    FreeS/WAN provides privacy for Internet packets using the proposed
    standard Internet Protocol Security (IPSEC) protocols.  FreeS/WAN
    negotiates strong keys using Diffie-Hellman key agreement with 1024-bit
    keys, and encrypts each packet with 168-bit Triple-DES (3DES).  A modern
    $500 PC can set up a tunnel in less than a second, and can encrypt
    6 megabits of packets per second, easily handling the whole available
    bandwidth at the vast majority of Internet sites.  In preliminary testing,
    FreeS/WAN interoperated with 3DES IPSEC products from OpenBSD, PGP, SSH,
    Cisco, Raptor, and Xedia.  Since FreeS/WAN is distributed as source code,
    its innards are open to review by outside experts and sophisticated users,
    reducing the chance of undetected bugs or hidden security compromises.

    The software has been in development for several years.  It has been
    funded by several philanthropists interested in increased privacy on
    the Internet, including John Gilmore, co-founder of the Electronic
    Frontier Foundation, a leading online civil rights group.

    Press contacts:
    Hugh Daniel,   +1 408 353 8124, hugh@toad.com
    Henry Spencer, +1 416 690 6561, henry@spsystems.net

    * FreeS/WAN derives its name from S/WAN, which is a trademark of RSA Data
      Security, Inc; used by permission.

Contents Previous Next