diff options
Diffstat (limited to 'doc/src/politics.html')
| -rw-r--r-- | doc/src/politics.html | 1466 |
1 files changed, 0 insertions, 1466 deletions
diff --git a/doc/src/politics.html b/doc/src/politics.html deleted file mode 100644 index 9e87d4f05..000000000 --- a/doc/src/politics.html +++ /dev/null @@ -1,1466 +0,0 @@ -<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> |