diff options
author | Rene Mayrhofer <rene@mayrhofer.eu.org> | 2006-05-22 05:12:18 +0000 |
---|---|---|
committer | Rene Mayrhofer <rene@mayrhofer.eu.org> | 2006-05-22 05:12:18 +0000 |
commit | aa0f5b38aec14428b4b80e06f90ff781f8bca5f1 (patch) | |
tree | 95f3d0c8cb0d59d88900dbbd72110d7ab6e15b2a /doc/src/politics.html | |
parent | 7c383bc22113b23718be89fe18eeb251942d7356 (diff) | |
download | vyos-strongswan-aa0f5b38aec14428b4b80e06f90ff781f8bca5f1.tar.gz vyos-strongswan-aa0f5b38aec14428b4b80e06f90ff781f8bca5f1.zip |
Import initial strongswan 2.7.0 version into SVN.
Diffstat (limited to 'doc/src/politics.html')
-rw-r--r-- | doc/src/politics.html | 1466 |
1 files changed, 1466 insertions, 0 deletions
diff --git a/doc/src/politics.html b/doc/src/politics.html new file mode 100644 index 000000000..9e87d4f05 --- /dev/null +++ b/doc/src/politics.html @@ -0,0 +1,1466 @@ +<html> +<head> + <meta http-equiv="Content-Type" content="text/html"> + <title>History and politics of cryptography</title> + <meta name="keywords" + content="Linux, IPsec, VPN, security, FreeSWAN, cryptography, history, politics"> + <!-- + + Written by Sandy Harris for the Linux FreeS/WAN project + Freely distributable under the GNU General Public License + + More information at www.freeswan.org + Feedback to users@lists.freeswan.org + + CVS information: + RCS ID: $Id: politics.html,v 1.1 2004/03/15 20:35:24 as Exp $ + Last changed: $Date: 2004/03/15 20:35:24 $ + Revision number: $Revision: 1.1 $ + + CVS revision numbers do not correspond to FreeS/WAN release numbers. + --> +</head> + +<body> +<h1><a name="politics">History and politics of cryptography</a></h1> + +<p>Cryptography has a long and interesting history, and has been the subject +of considerable political controversy.</p> + +<h2><a name="intro.politics">Introduction</a></h2> + +<h3>History</h3> + +<p>The classic book on the history of cryptography is David Kahn's <a +href="biblio.html#Kahn">The Codebreakers</a>. It traces codes and +codebreaking from ancient Egypt to the 20th century.</p> + +<p>Diffie and Landau <a href="biblio.html#diffie">Privacy on the Line: The +Politics of Wiretapping and Encryption</a> covers the history from the First +World War to the 1990s, with an emphasis on the US.</p> + +<h4>World War II</h4> + +<p>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.</p> + +<p>There are many books on this period. See our bibliography for several. Two +I particularly like are:</p> +<ul> + <li>Andrew Hodges has done a superb <a + href="http://www.turing.org.uk/book/">biography</a> of Alan Turing, a key + player among the Ultra codebreakers. Turing was also an important + computer pioneer. The terms <a + href="http://www.abelard.org/turpap/turpap.htm">Turing test</a> and <a + href="http://plato.stanford.edu/entries/turing-machine/">Turing + machine</a> are named for him, as is the <a + href="http://www.acm.org">ACM</a>'s highest technical <a + href="http://www.acm.org/awards/taward.html">award</a>.</li> + <li>Neal Stephenson's <a href="biblio.html#neal">Cryptonomicon</a> is a + novel with cryptography central to the plot. Parts of it take place + during WW II, other parts today.</li> +</ul> + +<p>Bletchley Park, where much of the Ultra work was done, now has a museum +and a <a href="http://www.bletchleypark.org.uk/">web site</a>.</p> + +<p>The Ultra work introduced three major innovations.</p> +<ul> + <li>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 + recruited bright young mathematicians to crack 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.</li> + <li>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.</li> + <li>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.</li> +</ul> + +<p>So by the end of the war, Allied code-breakers were expert at large-scale +mechanised code-breaking. The payoffs were enormous.</p> + +<h4><a name="postwar">Postwar and Cold War</a></h4> + +<p>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.</p> + +<p>America's <a href="glossary.html#NSA">NSA</a>, 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 <a +href="http://www.fas.org/irp/nsa/nsabudget.html">estimates</a>.</p> + +<p>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.</p> + +<p>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:</p> +<ul> + <li>Bamford's <a href="biblio.html#puzzle">The Puzzle Palace</a>, a history + of the NSA</li> + <li>Hager's <a href="http://www.fas.org/irp/eprint/sp/index.html">Secret + Power</a>, about the <a + href="http://sg.yahoo.com/government/intelligence/echelon_network/">Echelon</a> + system -- the US, UK, Canada, Australia and New Zealand co-operating to + monitor much of the world's communications.</li> +</ul> + +<p>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:</p> +<ul> + <li>actions of the English-speaking democracies not covered in those + books</li> + <li>actions of other more-or-less sane governments</li> + <li>the activities of various more-or-less insane governments</li> + <li>possibilities for unauthorized action by government employees</li> + <li>possible actions by large non-government organisations: corporations, + criminals, or conspiracies</li> +</ul> + +<p>might be really frightening.</p> + +<h4><a name="recent">Recent history -- the crypto wars</a></h4> + +<p>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.</p> + +<p>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:</p> +<ul> + <li>The US gov't established the Data Encryption Standard, <a + href="glossary.html#DES">DES</a>, a <a href="glossary.html#block">block + cipher</a> for cryptographic protection of unclassfied documents.</li> + <li>DES also became widely used in industry, especially regulated + industries such as banking.</li> + <li>Other nations produced their own standards, such as <a + href="glossary.html#GOST">GOST</a> in the Soviet Union.</li> + <li><a href="glossary.html#public">Public key</a> cryptography was invented + by Diffie and Hellman.</li> + <li>Academic conferences such as <a + href="http://www-cse.ucsd.edu/users/mihir/crypto2k.html">Crypto</a> and + <a + href="http://www.esat.kuleuven.ac.be/cosic/eurocrypt2000/">Eurocrypt</a> + began.</li> + <li>Several companies began offerring cryptographic products: <a + href="glossary.html#RSAco">RSA</a>, <a href="glossary.html#PGPI">PGP</a>, + the many vendors with <a href="glossary.html#PKI">PKI</a> products, + ...</li> + <li>Cryptography appeared in other products: operating systems, word + processors, ...</li> + <li>Network protocols based on crypto were developed: <a + href="glossary.html#SSH">SSH</a>, <a href="glossary.html#SSL">SSL</a>, <a + href="glossary.html#IPsec">IPsec</a>, ...</li> + <li>Crytography came into widespread use to secure bank cards, terminals, + ...</li> + <li>The US government replaced <a href="glossary.html#DES">DES</a> with the + much stronger Advanced Encryption Standard, <a + href="glossary.html#AES">AES</a></li> +</ul> + +<p>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 <a +href="http://online.offshore.com.ai/security/">cypherpunk</a> crypto +advocates, wanting to encourage widespread use.</p> + +<p>Steven Levy has written a fine history of much of this, called <a +href="biblio.html#crypto">Crypto: How the Code rebels Beat the Government -- +Saving Privacy in the Digital Age</a>.</p> + +<p>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 +<a +href="http://www.eff.org/pub/Privacy/Crypto_misc/cypherpunk.manifesto">Cypherpunk +Manifesto</a>:</p> + +<blockquote> + Privacy is necessary for an open society in the electronic age. ... + + <p>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. + ...</p> + + <p>We must defend our own privacy if we expect to have any. ...</p> + + <p>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.</p> + + <p>Cypherpunks deplore regulations on cryptography, for encryption is + fundamentally a private act. ...</p> + + <p>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. + ...</p> +</blockquote> + +<p>To quote project leader John Gilmore:</p> + +<blockquote> + 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.</blockquote> + +<p>If FreeS/WAN reaches its goal of making <a +href="intro.html#opp.intro">opportunistic encryption</a> widespread so that +secure communication can become the default for a large part of the net, we +will have struck a major blow.</p> + +<h3><a name="intro.poli">Politics</a></h3> + +<p>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.</p> + +<p>Things various governments have tried or are trying include:</p> +<ul> + <li>Echelon, a monitor-the-world project of the US, UK, NZ, Australian and + Canadian <a href="glossary.html#SIGINT">signals intelligence</a> + agencies. See this <a + href="http://sg.yahoo.com/government/intelligence/echelon_network/">collection</a> + of links and this <a + href="http://www.zdnet.com/zdnn/stories/news/0,4586,2640682,00.html">story</a> + on the French Parliament's reaction.</li> + <li>Others governments may well have their own Echelon-like projects. To + quote the Dutch Minister of Defense, as reported in a German <a + href="http://www.heise.de/tp/english/inhalt/te/4729/1.html">magazine</a>: + + <blockquote> + 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.</blockquote> + Even if they have nothing on the scale of Echelon, most intelligence + agencies and police forces certainly have some interception + capability.</li> + <li><a href="glossary.html#NSA">NSA</a> tapping of submarine communication + cables, described in <a + href="http://www.zdnet.com/zdnn/stories/news/0,4586,2764372,00.html">this + article</a></li> + <li>A proposal for international co-operation on <a + href="http://www.heise.de/tp/english/special/enfo/4306/1.html">Internet + surveillance</a>.</li> + <li>Alleged <a href="http://cryptome.org/nsa-sabotage.htm">sabotage</a> of + security products by the <a href="glossary.html#NSA">NSA</a> (the US + signals intelligence agency).</li> + <li>The German armed forces and some government departments will stop using + American software for fear of NSA "back doors", according to this <a + href="http://www.theregister.co.uk/content/4/17679.html">news + story</a>.</li> + <li>The British Regulation of Investigatory Powers bill. See this <a + href="http://www.fipr.org/rip/index.html">web page.</a> and perhaps this + <a + href="http://ars.userfriendly.org/cartoons/?id=20000806&mode=classic">cartoon</a>.</li> + <li>A Russian <a + href="http://www.eff.org/pub/Privacy/Foreign_and_local/Russia/russian_crypto_ban_english.edict">ban</a> + on cryptography</li> + <li>Chinese <a + href="http://www.eff.org/pub/Misc/Publications/Declan_McCullagh/www/global/china">controls</a> + on net use.</li> + <li>The FBI's carnivore system for covert searches of email. See this <a + href="http://www.zdnet.com/zdnn/stories/news/0,4586,2601502,00.html">news + coverage</a> and this <a + href="http://www.crypto.com/papers/carnivore-risks.html">risk + assessment</a>. The government had an external review of some aspects of + this system done. See this <a + href="http://www.crypto.com/papers/carnivore_report_comments.html">analysis</a> + of that review. Possible defenses against Carnivore include: + <ul> + <li><a href="glossary.html#PGP">PGP</a> for end-to-end mail + encryption</li> + <li><a href="http://www.home.aone.net.au/qualcomm/">secure sendmail</a> + for server-to-server encryption</li> + <li>IPsec encryption on the underlying IP network</li> + </ul> + </li> + <li>export laws restricting strong cryptography as a munition. See <a + href="#exlaw">discussion</a> below.</li> + <li>various attempts to convince people that fundamentally flawed + cryptography, such as encryption with a <a href="#escrow">back door</a> + for government access to data or with <a href="#shortkeys">inadequate key + lengths</a>, was adequate for their needs.</li> +</ul> + +<p>Of course governments are by no means the only threat to privacy and +security on the net. Other threats include:</p> +<ul> + <li>industrial espionage, as for example in this <a + href="http://www.zdnet.com/zdnn/stories/news/0,4586,2626931,00.html">news + story</a></li> + <li>attacks by organised criminals, as in this <a + href="http://www.sans.org/newlook/alerts/NTE-bank.htm">large-scale + attack</a></li> + <li>collection of personal data by various companies. + <ul> + <li>for example, consider the various corporate winners of Privacy + International's <a + href="http://www.privacyinternational.org/bigbrother/">Big Brother + Awards</a>.</li> + <li><a href="http://www.zeroknowledge.com">Zero Knowledge</a> sell + tools to defend against this</li> + </ul> + </li> + <li>individuals may also be a threat in a variety of ways and for a variety + of reasons</li> + <li>in particular, an individual with access to government or industry data + collections could do considerable damage using that data in unauthorized + ways.</li> +</ul> + +<p>One <a +href="http://www.zdnet.com/zdnn/stories/news/0,4586,2640674,00.html">study</a> +enumerates threats and possible responses for small and medium businesses. +VPNs are a key part of the suggested strategy.</p> + +<p>We consider privacy a human right. See the UN's <a href="http://www.un.org/Overview/rights.html">Universal +Declaration of Human Rights</a>, article twelve:</p> + +<blockquote> + No one shall be subjected to arbitrary interference with his privacy, + family, home or correspondence, nor to attacks upon his honor and + reputation. Everyone has the right to the protection of the law against + such interference or attacks.</blockquote> + +<p>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.</p> + +<h3>Links</h3> + +<p>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:</p> +<ul> + <li>the EFF's <a href="http://www.eff.org/crypto/">Privacy Now!</a> + campaign</li> + <li>the <a href="http://www.gilc.org">Global Internet Liberty + Campaign</a></li> + <li><a href="http://www.cpsr.org/program/privacy/privacy.html">Computer + Professionals for Social Responsibility</a></li> +</ul> + +<p>For more on these issues see:</p> +<ul> + <li>Steven Levy (Newsweek's chief technology writer and author of the + classic "Hackers") new book <a href="biblio.html#crypto">Crypto: How the + Code Rebels Beat the Government--Saving Privacy in the Digital + Age</a></li> + <li>Simson Garfinkel (Boston Globe columnist and author of books on <a + href="biblio.html#PGP">PGP</a> and <a href="biblio.html#practical">Unix + Security</a>) book <a href="biblio.html#Garfinkel">Database Nation: the + death of privacy in the 21st century</a></li> +</ul> + +<p>There are several collections of <a href="web.html#quotes">crypto +quotes</a> on the net.</p> + +<p>See also the <a href="biblio.html">bibliography</a> and our list of <a +href="web.html#policy">web references</a> on cryptography law and policy.</p> + +<h3>Outline of this section</h3> + +<p>The remainder of this section includes two pieces of writing by our +project leader</p> +<ul> + <li>his <a href="#gilmore">rationale</a> for starting this</li> + <li>another <a href="#policestate">discussion</a> of project goals</li> +</ul> + +<p>and discussions of:</p> +<ul> + <li><a href="#desnotsecure">why we do not use DES</a></li> + <li><a href="#exlaw">cryptography export laws</a></li> + <li>why <a href="#escrow">government access to keys</a> is not a good + idea</li> + <li>the myth that <a href="#shortkeys">short keys</a> are adequate for some + security requirements</li> +</ul> + +<p>and a section on <a href="#press">press coverage of FreeS/WAN</a>.</p> + +<h2><a name="leader">From our project leader</a></h2> + +<p>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 <a +href="http://www.toad.com/gnu/">home page</a>.</p> + +<center> +<h3><a name="gilmore">Swan: Securing the Internet against Wiretapping</a></h3> +</center> + +<p>My project for 1996 was to <b>secure 5% of the Internet traffic against +passive wiretapping</b>. 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. <a href="http://www.rsa.com/rsa/SWAN/">RSA</a> came up with +the term "S/WAN". Our main web site is at <a +href="http://www.freeswan.org/">http://www.freeswan.org/</a>. Want to +help?</p> + +<p>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.</p> + +<p>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.</p> + +<p>This wasn't just my idea; lots of people have been working on it for +years. The encryption protocols for these boxes are called <a +href="glossary.html#IPsec">IPSEC (IP Security)</a>. They have been developed +by the <a +href="http://www.ietf.cnri.reston.va.us/html.charters/ipsec-charter.html">IP +Security Working Group</a> of the <a href="http://www.ietf.org/">Internet +Engineering Task Force</a>, and will be a standard part of the next major +version of the Internet protocols (<a +href="http://playground.sun.com/pub/ipng/html/ipng-main.html">IPv6</a>). For +today's (IP version 4) Internet, they are an option.</p> + +<p>The <a href="http://www.iab.org/iab">Internet Architecture Board</a> and +<a href="http://www.ietf.org/">Internet Engineering Steering Group</a> have +taken a <a href="iab-iesg.stmt">strong stand</a> 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.</p> + +<p>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.</p> + +<h4>Deployment of IPSEC</h4> + +<p>The US government would like to control the deployment of IP Security with +its <a href="#exlaw">crypto export laws</a>. 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. <a +href="http://www.linux.org/">Linux</a> 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 <a +href="glossary.html#GPL">GNU Public License</a>, 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.</p> + +<p>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.</p> + +<p>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.</p> + +<p>There will also be numerous commercially available firewalls that use this +technology. <a href="http://www.rsa.com/">RSA Data Security</a> is +coordinating the <a href="http://www.rsa.com/rsa/SWAN">S/Wan (Secure Wide +Area Network)</a> project among more than a dozen vendors who use these +protocols. There's a <a +href="http://www.rsa.com/rsa/SWAN/swan_test.htm">compatability chart</a> that +shows which vendors have tested their boxes against which other vendors to +guarantee interoperatility.</p> + +<p>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.</p> + +<h4>Current status</h4> + +<p>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 +(<a +href="ftp://ftp.xs4all.nl/freeswan/freeswan-1.0.tar.gz">freeswan-1.0.tar.gz</a>), +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.</p> +<dl> + <dt>Protocols</dt> + <dd>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.</dd> + <dt>Linux Implementation</dt> + <dd>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.</dd> + <dt>Domain Name System Security</dt> + <dd>There is now a release of BIND 8.2 that includes most DNS Security + features. + <p>The first prototype implementation of Domain Name System Security + was funded by <a href="glossary.html#DARPA">DARPA</a> as part of their + <a href="http://www.darpa.mil/ito/research/is/index.html">Information + Survivability program</a>. <a href="http://www.tis.com">Trusted + Information Systems</a> wrote a modified version of <a + href="http://www.isc.org/bind.html">BIND</a>, the widely-used Berkeley + implementation of the Domain Name System.</p> + <p>TIS, ISC, and I merged the prototype into the standard version of + BIND. The first production version that supports KEY and SIG records is + <b>bind-4.9.5</b>. This or any later version of BIND will do for + publishing keys. It is available from the <a + href="http://www.isc.org/bind.html">Internet Software Consortium</a>. + 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.</p> + </dd> +</dl> + +<h4>Why?</h4> + +<p>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.</p> + +<h4>What You Can Do</h4> +<dl> + <dt>Install the latest BIND at your site.</dt> + <dd>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 <i>named</i>, the Name Daemon, which knows about the new + KEY and SIG record types. So, download it from the <a + href="http://www.isc.org/bind.html">Internet Software Consortium </a> + 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.</dd> + <dt>Set up a Linux system and run a 2.0.x kernel on it</dt> + <dd>Get a machine running Linux (say the 5.2 release from <a + href="http://www.redhat.com">Red Hat</a>). Give the machine two + Ethernet cards.</dd> + <dt>Install the Linux IPSEC (Freeswan) software</dt> + <dd>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.</dd> + <dt>Get on the linux-ipsec mailing list</dt> + <dd>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 <a + href="mailto:linux-ipsec-REQUEST@clinet.fi">linux-ipsec-REQUEST@clinet.fi</a> + 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").</dd> + + <p></p> + <dt>Check back at this web page every once in a while</dt> + <dd>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.</dd> +</dl> + +<p>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.</p> + +<h4>Related projects</h4> +<dl> + <dt>IPSEC for NetBSD</dt> + <dd>This prototype implementation of the IP Security protocols is for + another free operating system. <a + href="ftp://ftp.funet.fi/pub/unix/security/net/ip/BSDipsec.tar.gz">Download + BSDipsec.tar.gz</a>.</dd> + <dt>IPSEC for <a href="http://www.openbsd.org">OpenBSD</a></dt> + <dd>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.</dd> +</dl> + +<h3><a name="policestate">Stopping wholesale monitoring</a></h3> + +<p>From a message project leader John Gilmore posted to the mailing list:</p> +<pre>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.</pre> + +<p>Notes on things mentioned in that message:</p> +<ul> + <li>Denker is a co-author of a <a href="intro.html#applied">paper</a> on a + large FreeS/WAN application.</li> + <li>Information on Zero Knowledge is on their <a + href="http://www.zks.net/">web site</a>. Their Freedom product, designed + to provide untracable pseudonyms for use on the net, is no longer + marketed.</li> + <li>Another section of our documentation discusses ways to <a + href="ipsec.html#traffic.resist">resist traffic analysis</a>.</li> +</ul> + +<h2><a name="weak">Government promotion of weak crypto</a></h2> + +<p>Various groups, especially governments and especially the US government, +have a long history of advocating various forms of bogus security.</p> + +<p>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.</p> + +<p><strong>Avoiding bogus security is a key design criterion for everything +we do in FreeS/WAN</strong>. The most conspicuous example is our refusal to +support <a href="#desnotsecure">single DES</a>. Other IPsec "features" which +we do not implement are discussed in our <a +href="compat.html#dropped">compatibility</a> document.</p> + +<h3><a name="escrow">Escrowed encryption</a></h3> + +<p>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.</p> +<pre> Mary had a little key - she kept it in escrow, + and every thing that Mary said, + the feds were sure to know.</pre> + +<p>A <a href="web.html#quotes">crypto quotes</a> page attributes this to <a +href="http://www.scramdisk.clara.net/">Sam Simpson</a>.</p> + +<p>There is an excellent paper available on <a +href="http://www.cdt.org/crypto/risks98/">Risks of Escrowed Encryption</a>, +from a group of cryptographic luminaries which included our project +leader.</p> + +<p>Like any unnecessary complication, GAK tends to weaken security of any +design it infects. For example:</p> +<ul> + <li>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 <a + href="http://www.crypto.com/papers/">papers</a> page.</li> + <li>a rather <a href="http://www.pgp.com/other/advisories/adk.asp">nasty + bug</a> was found in the "additional decryption keys" "feature" of some + releases of <a href="glossary.html#PGP">PGP</a></li> +</ul> + +<p>FreeS/WAN does not support escrowed encryption, and never will.</p> + +<h3><a name="shortkeys">Limited key lengths</a></h3> + +<p>Various governments, and some vendors, have also made persistent attempts +to convince people that:</p> +<ul> + <li>weak systems are sufficient for some data</li> + <li>strong cryptography should be reserved for cases where the extra + overheads are justified</li> +</ul> + +<p><strong>This is utter nonsense</strong>.</p> + +<p>Weak systems touted include:</p> +<ul> + <li>the ludicrously weak (deliberately crippled) 40-bit ciphers that until + recently were all various <a href="#exlaw">export laws</a> allowed</li> + <li>56-bit single DES, discussed <a href="#desnotsecure">below</a></li> + <li>64-bit symmetric ciphers and 512-bit RSA, the maximums for unrestricted + export under various current laws</li> +</ul> + +<p>The notion that choice of ciphers or keysize should be determined by a +trade-off between security requirements and overheads is pure bafflegab.</p> +<ul> + <li>For most <a href="glossary.html#symmetric">symmetric ciphers</a>, it is + simply a lie. Any block cipher has some natural maximum keysize inherent + in the design -- 128 bits for <a href="glossary.html#IDEA">IDEA</a> or <a + href="glossary.html#CAST128">CAST-128</a>, 256 for Serpent or Twofish, + 448 for <a href="glossary.html#Blowfish">Blowfish</a> and 2048 for <a + href="glossary.html#RC4">RC4</a>. Using a key size smaller than that + limit gives <em>exactly zero </em>savings in overhead. The crippled + 40-bit or 64-bit version of the cipher provides <em>no advantage + whatsoever</em>.</li> + <li><a href="glossary.html#AES">AES</a> uses 10 rounds with 128-bit keys, + 12 rounds for 192-bit and 14 rounds for 256-bit, so there actually is a + small difference in overhead, but not enough to matter in most + applications.</li> + <li>For <a href="glossary.html#3DES">triple DES</a> there is a grain of + truth in the argument. 3DES is indeed three times slower than single DES. + However, the solution is not to use the insecure single DES, but to pick + a faster secure cipher. <a href="glossary.html#CAST128">CAST-128</a>, <a + href="glossary.html#Blowfish">Blowfish</a> and the <a + href="glossary.html#AES">AES candidate</a> ciphers are are all + considerably faster in software than DES (let alone 3DES!), and + apparently secure.</li> + <li>For <a href="glossary.html#public">public key</a> techniques, there are + extra overheads for larger keys, but they generally do not affect overall + performance significantly. Practical public key applications are usually + <a href="glossary.html#hybrid">hybrid</a> 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. + <p>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.</p> + </li> +</ul> + +<p>In short, <strong>there has never been any technical reason to use +inadequate ciphers</strong>. 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.</p> +<pre> Mary had a little key (It's all she could export), + and all the email that she sent was opened at the Fort.</pre> + +<p>A <a href="web.html#quotes">crypto quotes</a> page attributes this to <a +href="http://theory.lcs.mit.edu:80/~rivest/">Ron Rivest</a>. NSA headquarters +is at Fort Meade, Maryland.</p> + +<p>Our policy in FreeS/WAN is to use only cryptographic components with +adequate keylength and no known weaknesses.</p> +<ul> + <li>We do not implement single DES because it is clearly <a + href="#desnotsecure">insecure</a>, so implemeting it would violate our + policy of avoiding bogus security. Our default cipher is <a + href="glossary.html#3DES">3DES</a></li> + <li>Similarly, we do not implement the 768-bit Group 1 for <a + href="glossary.html#DH">Diffie-Hellman</a> key negotiation. We provide + only the 1024-bit Group 2 and 1536-bit Group 5.</li> +</ul> + +<p>Detailed discussion of which IPsec features we implement or omit is in out +<a href="compat.html">compatibility document</a>.</p> + +<p>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.</p> + +<p>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 <a href="glossary.html#IETF">IETF</a> +working groups.</p> + +<h4>Some real trade-offs</h4> + +<p>Of course, making systems secure does involve costs, and trade-offs can be +made between cost and security. However, the real trade-offs have nothing to +do with using weaker ciphers.</p> + +<p>There can be substantial hardware and software costs. There are often +substantial training costs, both to train administrators and to increase user +awareness of security issues and procedures. There are almost always +substantial staff or contracting costs.</p> + +<p>Security takes staff time for planning, implementation, testing 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.</p> + +<p>Moreover, someone in your organisation (or on contract to it) needs to +spend considerable time keeping up with new developments. EvilDoers +<em>will</em> know about new attacks shortly after they are found. You need +to know about them before your systems are attacked. If your vendor provides +a patch, you need to apply it. If the vendor does nothing, you need to +complain or start looking for another vendor.</p> + +<p>For a fairly awful example, see this <a +href="http://www.sans.org/newlook/alerts/NTE-bank.htm">report</a>. 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.</p> + +<p>At an absolute minimum, you must do something about such issues +<em>before</em> 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.</p> + +<p>Compared to those costs, cipher overheads are an insignificant factor in +the cost of security.</p> + +<p>The only thing using a weak cipher can do for you is to cause all your +other investment to be wasted.</p> + +<h2><a name="exlaw">Cryptography Export Laws</a></h2> + +<p>Many nations restrict the export of cryptography and some restrict its use +by their citizens or others within their borders.</p> + +<h3><a name="USlaw">US Law</a></h3> + +<p>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 <a href="glossary.html#EAR">EAR</a> Export +Administration Regulations.</p> + +<p>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.</p> + +<p>The <a href="http://www.bxa.doc.gov/Encryption/">official website</a> for +these regulations is run by the Commerce Department's Bureau of Export +Administration (BXA).</p> + +<p>The <a href="http://www.eff.org/bernstein/">Bernstein case</a> 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.</p> + +<p>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 <a href="glossary.html#BXA">BXA</a>.</p> + +<p>There are, however, still restrictions in force. + 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.</p> + +<h4><a name="UScontrib">US contributions to FreeS/WAN</a></h4> + +<p>The FreeS/WAN project <strong>cannot accept software contributions, <em> +not even small bug fixes</em>, from US citizens or residents</strong>. 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.</p> + +<p>Of course Americans can still make valuable contributions (many already +have) by reporting bugs, or otherwise contributing to discussions, on the +project <a href="mail.html">mailing list</a>. Since the list is public, this +is clearly constitutionally protected free speech.</p> + +<p>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.</p> + +<h3><a name="wrong">What's wrong with restrictions on cryptography</a></h3> + +<p>Some quotes from prominent cryptography experts:</p> + +<blockquote> + 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.<br> + <a href="http://www.cl.cam.ac.uk/users/rja14"> Ross Anderson, Cambridge + University</a></blockquote> + +<blockquote> + If the government were honest about its motives, then the debate about + crypto export policy would have ended years ago.<br> + <a href="http://www.counterpane.com"> Bruce Schneier, Counterpane + Systems</a></blockquote> + +<blockquote> + The NSA regularly lies to people who ask it for advice on export control. + They have no reason not to; accomplishing their goal by any legal means is + fine by them. Lying by government employees is legal.<br> + John Gilmore.</blockquote> + +<p>The Internet Architecture Board (IAB) and the Internet Engineering +Steering Group (IESG) made a <a href="iab-iesg.stmt">strong statement</a> in +favour of worldwide access to strong cryptography. Essentially the same +statement is in the appropriately numbered <a +href="ftp://ftp.isi.edu/in-notes/rfc1984.txt">RFC 1984</a>. Two critical +paragraphs are:</p> + +<blockquote> + ... various governments have actual or proposed policies on access to + cryptographic technology ... + + <p>(a) ... export controls ...<br> + (b) ... short cryptographic keys ...<br> + (c) ... keys should be in the hands of the government or ...<br> + (d) prohibit the use of cryptology ...</p> + + <p>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, ...</p> + + <p>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.</p> +</blockquote> + +<p>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".</p> + +<p>More recently, the same two bodies (IESG and IAB) have issued <a +href="ftp://ftp.isi.edu/in-notes/rfc2804.txt">RFC 2804</a> on why the IETF +should not build wiretapping capabilities into protocols for the convenience +of security or law enforcement agenicies. The abstract from that document +is:</p> + +<blockquote> + The Internet Engineering Task Force (IETF) has been asked to take a + position on the inclusion into IETF standards-track documents of + functionality designed to facilitate wiretapping. + + <p>This memo explains what the IETF thinks the question means, why its + answer is "no", and what that answer means.</p> +</blockquote> +A quote from the debate leading up to that RFC: + +<blockquote> + 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.<br> + Jeff Schiller of MIT, in a discussion of FBI demands for wiretap capability + on the net, as quoted by <a + href="http://www.wired.com/news/politics/0,1283,31895,00.html">Wired</a>.</blockquote> + +<p>The <a href="http://www.ietf.org/mailman/listinfo/raven">Raven</a> mailing +list was set up for this IETF discussion.</p> + +<p>Our goal is to go beyond that RFC and prevent Internet wiretapping +entirely.</p> + +<h3><a name="Wassenaar">The Wassenaar Arrangement</a></h3> + +<p>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.</p> + +<p>A number of countries:</p> + +<p>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</p> + +<p>have signed the Wassenaar Arrangement which restricts export of munitions +and other tools of war. Cryptographic sofware is covered there.</p> + +<p>Wassenaar details are available from the <a +href="http://www.wassenaar.org/"> Wassenaar Secretariat</a>, and elsewhere in +a more readable <a href="http://www.fitug.de/news/wa/index.html"> HTML +version</a>.</p> + +<p>For a critique see the <a href="http://www.gilc.org/crypto/wassenaar"> +GILC site</a>:</p> + +<blockquote> + The Global Internet Liberty Campaign (GILC) has begun a campaign calling + for the removal of cryptography controls from the Wassenaar Arrangement. + + <p>The aim of the Wassenaar Arrangement is to prevent the build up of + military capabilities that threaten regional and international security and + stability . . .</p> + + <p>There is no sound basis within the Wassenaar Arrangement for the + continuation of any export controls on cryptographic products.</p> +</blockquote> + +<p>We agree entirely.</p> + +<p>An interesting analysis of Wassenaar can be found on the <a +href="http://www.cyber-rights.org/crypto/wassenaar.htm">cyber-rights.org</a> +site.</p> + +<h3><a name="status">Export status of Linux FreeS/WAN</a></h3> + +<p>We believe our software is entirely exempt from these controls since the +Wassenaar <a +href="http://www.wassenaar.org/list/GTN%20and%20GSN%20-%2099.pdf">General +Software Note</a> says:</p> + +<blockquote> + The Lists do not control "software" which is either: + <ol> + <li>Generally available to the public by . . . retail . . . or</li> + <li>"In the public domain".</li> + </ol> +</blockquote> + +<p>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.</p> + +<p>Their glossary defines "In the public domain" as:</p> + +<blockquote> + . . . "technology" or "software" which has been made available without + restrictions upon its further dissemination. + + <p>N.B. Copyright restrictions do not remove "technology" or "software" + from being "in the public domain".</p> +</blockquote> + +<p>We therefore believe that software freely distributed under the <a +href="glossary.html#GPL">GNU Public License</a>, such as Linux FreeS/WAN, is +exempt from Wassenaar restrictions.</p> + +<p>Most of the development work is being done in Canada. Our understanding is +that the Canadian government accepts this interpretation.</p> +<ul> + <li>A web statement of <a + href="http://www.dfait-maeci.gc.ca/~eicb/notices/ser113-e.htm"> Canadian + policy</a> is available from the Department of Foreign Affairs and + International Trade.</li> + <li>Another document from that department states that <a + href="http://www.dfait-maeci.gc.ca/~eicb/export/gr1_e.htm">public domain + software</a> is exempt from the export controls.</li> + <li>A researcher's <a + href="http://insight.mcmaster.ca/org/efc/pages/doc/crypto-export.html">analysis</a> + of Canadian policy is also available.</li> +</ul> + +<p>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."</p> + +<h3><a name="help">Help spread IPsec around</a></h3> + +<p>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 <a href="intro.html#munitions">munitions</a> Linux crypto software +archive.</p> + +<p>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).</p> + +<p>Please send a note about any new archive mirror sites or CD distributions +to linux-ipsec@clinet.fi so we can update the documentation.</p> + +<p>Lists of current <a href="intro.html#sites">mirror sites</a> and of <a +href="intro.html#distwith">distributions</a> which include FreeS/WAN are in +our introduction section.</p> + +<h2><a name="desnotsecure">DES is Not Secure</a></h2> + +<p>DES, the <strong>D</strong>ata <strong>E</strong>ncryption +<strong>S</strong>tandard, can no longer be considered secure. While no major +flaws in its innards are known, it is fundamentally inadequate because its +<strong>56-bit key is too short</strong>. It is vulnerable to <a +href="glossary.html#brute">brute-force search</a> 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 <strong>any other +cipher with only a 56-bit key</strong>. The only reason anyone could have for +using a 56 or 64-bit key is to comply with various <a +href="exportlaw.html">export laws</a> intended to ensure the use of breakable +ciphers.</p> + +<p>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.</p> + +<p>A group of well-known cryptographers looked at key lengths in a <a +href="http://www.counterpane.com/keylength.html"> 1996 paper</a>. They +suggested a <em>minimum</em> of 75 bits to consider an existing cipher secure +and a <em>minimum of 90 bits for new ciphers</em>. More recent papers, +covering both <a href="glossary.html#symmetric">symmetric</a> and <a +href="glossary.html#public">public key</a> systems are at <a +href="http://www.cryptosavvy.com/">cryptosavvy.com</a> and <a +href="http://www.rsasecurity.com/rsalabs/bulletins/bulletin13.html">rsa.com</a>. +For all algorithms, the minimum keylengths recommended in such papers are +significantly longer than the maximums allowed by various export laws.</p> + +<p>In a <a +href="http://www.privacy.nb.ca/cryptography/archives/cryptography/html/1998-09/0095.html">1998 +ruling</a>, a German court described DES as "out-of-date and not safe enough" +and held a bank liable for using it.</p> + +<h3><a name="deshware">Dedicated hardware breaks DES in a few days</a></h3> + +<p>The question of DES security has now been settled once and for all. In +early 1998, the <a href="http://www.eff.org/">Electronic Frontier +Foundation</a> built a <a +href="http://www.eff.org/descracker.html">DES-cracking machine</a>. 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 <a href="biblio.html#EFF"><cite>Cracking DES</cite></a>, by +the Electronic Frontier Foundation.</p> + +<p>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.</p> + +<p>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 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.</p> + +<p>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.</p> + +<p>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.</p> + +<h3><a name="spooks">Spooks may break DES faster yet</a></h3> + +<p>As for the security and intelligence agencies of various nations, they may +have had DES crackers for years, and theirs may be much faster. It is +difficult to make most computer applications work well on parallel machines, +or to design specialised hardware to accelerate them. Cipher-cracking is one +of the very few exceptions. It is entirely straightforward to speed up +cracking by just adding hardware. 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 <a href="http://www.planepage.com/">aviation +website</a> gives the cost of a B1 bomber as $200,000,000. Spending that +much, an intelligence agency could break DES in an average time of <em>six +and a half minutes</em>.</p> + +<p>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.</p> + +<p>In short, we have <em>no idea</em> how quickly these organisations can +break DES. Unless they're spectacularly incompetent or horribly underfunded, +they can certainly break it, but we cannot guess how quickly. Pick any time +unit between days and milliseconds; none is entirely unbelievable. More to +the point, none of them is of any comfort if you don't want such +organisations reading your communications.</p> + +<p>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.</p> + +<p>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. Certainly those countries +have some fine mathematicians, and those agencies had budget. How well did +they succeed? Is their technology now for sale or rent?</p> + +<h3><a name="desnet">Networks break DES in a few weeks</a></h3> + +<p>Before the definitive EFF effort, DES had been cracked several times by +people using many machines. See this <a +href="http://www.distributed.net/pressroom/DESII-1-PR.html"> press +release</a> for example.</p> + +<p>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.</p> + +<p>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 . . .</p> + +<p>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?</p> + +<h3><a name="no_des">We disable DES</a></h3> + +<p>In short, it is now absolutely clear that <strong>DES is not +secure</strong> against</p> +<ul> + <li>any <strong>well-funded opponent</strong></li> + <li>any opponent (even a penniless one) with access (even stolen access) to + <strong>enough general purpose computers</strong></li> +</ul> + +<p>That is why <strong>Linux FreeS/WAN disables all transforms which use +plain DES</strong> for encryption.</p> + +<p>DES is in the source code, because we need DES to implement our default +encryption transform, <a href="glossary.html#3DES">Triple DES</a>. <strong>We +urge you not to use single DES</strong>. 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.</p> + +<h3><a name="40joke">40-bits is laughably weak</a></h3> + +<p>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 +<a href="#exlaw">export laws</a>. A brute force search of such a cipher's +keyspace is 2<sup>16</sup> 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 +<em>seconds</em>. One contest to crack a 40-bit cipher was won by a student +<a href="http://catless.ncl.ac.uk/Risks/18.80.html#subj1"> using a few +hundred idle machines at his university</a>. It took only three and half +hours.</p> + +<p>We do not, and will not, implement any 40-bit cipher.</p> + +<h3><a name="altdes">Triple DES is almost certainly secure</a></h3> + +<p><a href="glossary.html#3DES">Triple DES</a>, 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.</p> + +<p>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 <a href="glossary.html#benchmarks">speed +measurements</a> for our code are available.</p> + +<h3><a name="aes.ipsec">AES in IPsec</a></h3> + +<p>The <a href="glossary.html#AES">AES</a> project has 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.</p> + +<p>The winner, announced in October 2000 after several years of analysis and +discussion, was the <a +href="http://www.esat.kuleuven.ac.be/~rijmen/rijndael/">Rijndael</a> cipher +from two Belgian designers.</p> + +<p>It is almost certain that FreeS/WAN will add AES support. <a +href="web.html#patch">AES patches</a> are already available.</p> + +<h2><a name="press">Press coverage of Linux FreeS/WAN:</a></h2> + +<h3>FreeS/WAN 1.0 press</h3> +<ul> + <li><a + href="http://www.wired.com/news/news/technology/story/19136.html">Wired</a> + "Linux-Based Crypto Stops Snoops", James Glave April 15 1999</li> + <li><a + href="http://slashdot.org/articles/99/04/15/1851212.shtml">Slashdot</a></li> + <li><a href="http://dgl.com/itinfo/1999/it990415.html">DGL</a>, Damar Group + Limited; looking at FreeS/WAN from a perspective of business + computing</li> + <li><a href="http://linuxtoday.com/stories/5010.html">Linux Today</a></li> + <li><a href="http://www.tbtf.com/archive/1999-04-21.html#Tcep">TBTF</a>, + Tasty Bits from the Technology Front</li> + <li><a + href="http://www.salonmagazine.com/tech/log/1999/04/16/encryption/index.html">Salon + Magazine</a> "Free Encryption Takes a Big Step"</li> +</ul> + +<h3><a name="release">Press release for version 1.0</a></h3> +<pre> 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.</pre> +</body> +</html> |